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ABSTRACT 


Internetworking is the ability to seamlessly interconnect multiple dissimilar 
networks globally using the Internet (Brutzman, 96). In order to achieve this 
network, technology needs to provide speeds which will allow the network to 
function properly. Many applications which are used on this network demand a 
high bandwidth to perform effectively. 

This thesis presents an analysis of Basic Rate Interface (BRI) Integrated 
Services Digital Network (ISDN) as a data link technology for extending Local- 
Area Network (LAN) connectivity. Hardware and software capabilities are 
presented in detail. A representative “ISDN user needs analysis” is also 
provided. A study is made of an ISDN installation and implementation to 
determine if ISDN is a viable solution to extending LAN connectivity. 

Considerations of particular importance include Internet Protocol (IP) 
compatibility, bonding separate channels to act as a single 128 Kbps logical 
channel, and native support for IP multicast addressing. Experimental results 


indicate that ISDN meets most essential requirements. 
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I. INTRODUCTION 
A. PURPOSE OF THESIS 

Internetworking is the ability to seamlessly interconnect multiple dissimilar 
networks globally using the Internet (Brutzman, 96). In order to achieve this network, 
data links need to provide speeds which allow applications to function properly. Many 
important networked applications require high bandwidth to perform effectively. 

This thesis presents an analysis of Basic Rate Interface (BRI) Integrated Services 
Digital Network (ISDN) as a data link technology for extending Local-Area Network 
(LAN) connectivity. Hardware and Software capabilities are presented in detail. A 
representative ISDN user needs analysis is also provided. We then evaluate the practical 
employment of ISDN in the Systems Technology Lab (STL) in Root Hall to determine if 
ISDN is a viable solution. 

Considerations of particular importance include Internet Protocol (IP) 
compatibility, bonding separate channels to act as a single 128 Kbps logical channel, and 
native support for IP multicast addressing. Experiment results indicate that ISDN meets 
most essential requirements. 

B. MOTIVATION 

Many articles have been written on ISDN stating that the acronym stands for “It 
Still Does Nothing.” ISDN has been in existence for nearly ten years but its slow 
adoption has meant that ISDN still remains a mystery to many. For most of those ten 
years, it has been a proprietary implementation by the different telephone companies. 


There were no standards in place. This meant that different companies made products 


that supported different features of ISDN and were not interoperable with other ISDN 
products. 

Over the past few years, technology literature has claimed that ISDN has 
improved. The telephone companies are beginning to understand the technology that 
they are providing and are capable of trouble shooting problems. Standards are being 
made to make ISDN and ISDN products interoperable. (Ginsberg, 95) 

Many research analysts believe however that the improvements have come too 
late. They predict that up-and-coming technologies such as cable modems and 
Asymmetric Data Service Line (ADSL) will make ISDN obsolete (Leeds, 96). Both 
technologies offer speeds many times that of ISDN and wonder why anyone would 
bother with ISDN. 

This thesis will determine whether ISDN is of immediate practical use. ISDN 
needs to be evaluated fairly to determine the benefits of this technology, the costs 
associated with it, and its future growth with the DoD. 

ks The Importance Of New Technology In The DoD 

Periodically, DoD needs to re-evaluate its mission and determine the 
requirements need to accomplish its mission. The DoD also needs to have visionaries to 
determine how the mission will change and what future requirements will be needed. 
When performing this evaluation, existing technologies need to be examined to 
determine which technology can support the requirements. The existing technology 


selected needs to be able to migrate into future technologies. 


DoD can’t sit back and take a wait-and-see attitude when it comes to technology. 
There will always be something newer and better just waiting to be developed. DoD 
needs to be smarter in determining its mission and its requirements to accomplish its 
mission. 

The Internet is essential for many DoD tasks. The DoD need LANs, IP 
compatibility, telecommuting, IP multicast and bandwidth to be effective in these tasks. 
ISDN needs to be evaluated to determine it it can provide these requirements for these 
tasks. 

C: THESIS ORGANIZATION 

Chapter II identifies related work, in particular how ISDN is presently being used 
at the Naval Postgraduate School (NPS) and in the private sector. Chapter III is the 
detailed thesis problem statement. Chapter IV 1s the evolution of ISDN and how the 
Regional Bell Operating Companies (RBOCs) market the different ISDN services. 
Chapter V addresses typical user needs relative to ISDN. Chapter VI examines ISDN- 
related hardware. Chapter VII is the experimental results and Chapter VIII are the 


Conclusions and Recommendations. 
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UH. RELATED WORK 


ae INTRODUCTION 

This chapter discusses work relating to the larger shared objective of how to 
connect everyone using the Internet. Section B discusses research that was performed 
using the Multicast Backbone (MBone), a technology that provides global many-to-many 
real-time audio/video connectivity using the Internet. We believe that MBone 
compatibility is a key requirement for ISDN use. This section also discusses research 
occurring at the Naval Postgraduate School (NPS) which examines different technologies 
that can provide adequate bandwidth to run MBone tools and other applications running 
across an extended LAN. Section C and D discusses the current usage of ISDN at NPS 
and in the commercial sector respectively. 
B. INFORMATION INFRASTRUCTURE RESEARCH GROUP 

The Information Infrastructure Research Group (IIRG) is a team of thesis research 
students at NPS. Much of the students’ research shares a common objective: to connect 
everyone using the globally shared resource of the Internet. (IIRG, 96) 

The following are recently completed NPS theses that relate to connectivity using 
the MBone. Other related theses document various ways to utilize the MBone tools (as 


well as other applications) properly. 


Ie Hamming “Learning to Learn” Multicast Distance Learning 

Hamming “Learning to Learn” Multicast Distance Learning (Emswiler, 95) is a 
thesis that addresses how the MBone and its tools can be used effectively for desktop 
conferencing and distance learning. “Effective” in this context means the ability to have 
good audio/video quality across global Internet connections. “This thesis addresses the 
need to provide an interactive and cost effective way to teach and learn. It also shows 
how MBone is an economically feasible approach for providing widely distributed 
audio/video for distance learning. 

2: Planning and Implementing a Wide-Area Network (WAN) 

Internetworking: Planning and Implementing a Wide-Area Network (WAN) for 
K-12 Schools (Bigelow, 95) is a thesis that documents the planning, design and 
implementation of a regional WAN connecting K-12 schools, research institutions, 
libraries and institutions of higher education throughout the Monterey Bay area. The 
goal of the network is to enable students and educators to have access to the 
environmental resources available regionally via the Internet, at speeds which will 
encourage interaction and maintain interest. The thesis documents solutions 
implemented when connecting this WAN. It also lists deficiencies preventing 
endorsement of ISDN use as one of the solutions. Those deficiencies are listed in Figure 


JEN, 


Basic Rate Interface (BRI) ISDN is unacceptable due to low bandwidth with 
no compatible upgrade path. 


Current high cost of Pimary Rate ISDN is out of reach for schools. 


Vendor hardware solutions are proprietary and not interoperable. Multilink 
PPP may resolve this, but has not been implemented. 





Figure 2.1. Deficiencies preventing endorsement of ISDN use. From (Bigelow, 95). 


3. Global ATM Networks for Live Multicast Audio/Video 

Internetworking: Using Global ATM Networks for Live Multicast Audio/Video 
Distribution (Erdogan, 96) is a thesis that documents how distance learning has a positive 
impact on the quality of education and training for the Monterey Bay area. The thesis 
shows the implementation of the MBone over Monterey BayNet for educational 
purposes. The Monterey BayNet is a regional wide-area network (WAN) which connects 
K-12 schools, libraries, research institutions and institutions of higher education 
throughout the Monterey Bay Area. This thesis shows that the current MBone 
technology is possible over a Frame Relay Network. Most of the Frame Relay links 
tested provide network connections comparable to ISDN at 128 Kbps. 
e& ISDN AT NPS 

The biggest advertising pitch for ISDN used by the telephone companies has been 
to handle multiple telephone activities. Like many other organizations’ internal 


telephone office, NPS Base Communications is overloaded with multiple lines. There 


are not enough analog lines to handle all the employees that need access to a phone, fax 
or PC. ISDN service allows NPS Base Communications to handle these activities using 
multiple telephone numbers from a single line. To find out which offices use ISDN for 
their office needs at NPS, contact Jim Baker at NPS Base Communications. 

Except for providing voice telephone service to the school, ISDN lines have only 
been purchased in limited quantities. There is a Distance Learning Center (DLC) in Root 
Hall which uses ISDN technology to provide a room-size video teleconferencing (VTC) 
system. This VTC uses transmission speeds greater than 128 Kbps. Three Basic Rate 
Interface (BRI) lines, used for data, are “bonded” together to provide the necessary 
bandwidth. Point of contact for the DLC 1s Debbie Walsh whose office is Root Hall, 
Room 256. 

Some professors in the Computer Science Department use data ISDN to 
telecommute from home. Presently, the Computer Science Department has three ISDN 
lines installed and available to professors who have a need for this technology. 

Curiously, this high-speed capability is still considered nonessential at NPS. The demand 
by the user to deliver adequate bandwidth to maintain an acceptable data transfer rate 
does not outweigh the cost. Point of contact for these three lines is Rosalie Johnson. Her 
office is located in Spanagel Hall, room 527B. 

The Systems Technology Lab (STL) has installed one ISDN line for the purpose 
of conducting this thesis. They plan to install nine more in the future and have the lines 


connected to an ISDN hub. If this thesis successfully shows that ISDN supports 


multicasting, then the STL administrators will use ISDN to telecommute from home to 
the STL. They want to improve security in the STL by visually checking the lab 
remotely. Point of contact is Don McGregor whose office is located in Root Hall, room 
205D. 
D. ISDN IN THE PRIVATE SECTOR 

International Data Corporation (IDC) is an independent consultant firm that 
conducted a survey of telecommunication managers in 1995. The survey was conducted 
to determine the users opinion and projection for a variety of telecommunication products 
and services. The services were private-line speeds, data communication services, 
protocol environments, and the Internet. IDC interviewed telecommunication managers 
from companies with 100 or more employees from within the seven Regional Bell 
Operating Company (RBOC) segments. There were about 218 respondents in all. IDC 
analyzed the respondent’s perspective on a regional basis to focus on distinctions among 
regions. IDC also analyzed the data on an industry basis to focus on distinctions among 
industries. (Shapiro/Robertson, 95) 

1. IDC Findings 

Migration from private-line networks is slow. Thirty percent of the managers 
interviewed predict that their companies will not be migrating from the current private 
networks at all. However, IDC strongly believes that although the migration path 1s 
slow, the increasingly complex maintenance of these networks will drive many 


corporations to reconsider using alternative services like ISDN and asynchronous transfer 


mode (ATM) to create a more hybrid approach to their WAN service (Shapiro/Robertson, 
95). 

Appendix A shows the penetration of some telecommunication services for data 
traffic: basic exchange, private lines, switched 56 Kbps, and ISDN. Although only 30% 
of users use BRI ISDN and 16.5% use PRI ISDN, IDC predicts that each of these 
numbers will increase slowly in the future (Shapiro/Robertson, 95). Appendix A shows 
the mean and median data regarding number of connections for each service. 
Furthermore, interest in BRI ISDN has increased. IDC contributes this increase to the 
interest of remote LAN access and telecommuting. BRI ISDN has had the highest 
penetration in the agriculture, construction and mining markets. 
E. SUMMARY 

This chapter addresses related work which demonstrated a relationship between 
ISDN, the MBone software tools and distance learning. Other related work documents 
the need to find alternative technology solutions to successfully utilize the MBone tools 
as well as other bandwidth intensive applications. This chapter also addresses how ISDN 
is being deployed at NPS now and where some departments plan to use it in the future. 


Lastly, it shows the slow migration of ISDN in the private sector. 


Ii. PROBLEM STATEMENT 


AS INTRODUCTION 

The key challenge in network design is providing useful and manageable 
connectivity for users. More and more organizations are seeing the need to tie together 
their islands of automation. They are trying to achieve for data services what the 
telephone system already provides for voice services: the ability to communicate or be 
connected to another. Connectivity means allowing users to communicate up, down, 
across, and, in and out of an organization. (Sprague Jr/McNurlin, 93) 

This thesis 1s about just that, providing user connectivity by extending an 
organization’s LAN through the use of ISDN. Section B explains the need for 
connectivity. Section C explains the problems in achieving connectivity. Section D 
discusses video teleconferencing (VTC), an application which research has shown aids in 
communication. It also explains how the MBone technology can be used for VTC. 
Section E is the problem statement of this thesis; the need to evaluate the potential 
effectiveness of ISDN for connectivity. Section F discusses why it is important to 
evaluate ISDN within the Navy and Marine Corps. 

B. NEED FOR AN EXTENDED LAN 

There are many reasons why organizations are pushing for connectivity outside 

the organization. Figure 3.1 explains some of the major reasons and is by no means an 


exhaustive list. 


1] 


Economic constraints have caused organizations to look for alternative 
solutions to in-person meetings, and, education and training requirements that 
can not be provided locally. 


Geographical dispersion of workers can create problems for collaborative work 
to be performed. 


Organizations are realizing that employees can be equally or more productive 
working from their homes. In order to recruit and retain key personnel, 
organizations are providing their employees with the ability to telecommute 
from home. 


Transactions between businesses are increasingly being done electronically. 


Figure 3.1. Needs for an extended LAN. 





C. | CONNECTIVITY PROBLEMS AND A SOLUTION: INTERNET 
PROTOCOL (IP) 


The problem with extending connectivity is one of non-interoperabilities. 
Different machines use different operating systems with different hardware interfaces on 
different networks. These machines need to be interoperable. It is not always possible 
(and rarely desirable) to buy end-to-end equipment from the same vendor. The 
connectivity solution needs to be one that allows the exchange of information in standard 
ways without physical intervention and without any changes in the command language or 
in functionality. That is why interoperability must be stressed. Standards are the 
foundation of the overall architecture because they offer the greatest long-term benefits. 
Proprietary solutions are to be reserved for filling gaps where standards are not yet 
available. Therefore, there is only one practical solution for computer connectivity that 


simultaneously addresses all of these competing requirements: the Internet Protocol (IP). 


Iz 


D. VIDEO CONFERENCE SYSTEM NEEDED IN AN EXTENDED LAN 

Video teleconferencing (VTC) is not a new technology. Expensive room-sized 
systems incorporating specialized hardware and software components have been used for 
years. Organizations recognize them as productive tools and use them in distance 
learning and collaborative work. Unfortunately, these systems use proprietary hardware 
and software and do not interoperate with other computers due to incompatibility with IP. 

New video conferencing technology is downsizing these systems to inexpensive 
software that works on a PC. Desktop conferencing improves the communication 
process with other users. It allows the users to see each other. The subtleties of body 
language and facial expressions are communicated in a way not possible via fax machine, 
e-mail or telephone. As a result, the users avoid wasted time and avert 
misunderstandings. Additionally, desktop video conferencing systems allow individuals 
to participate in all functions that room-size systems allowed. As with the room-size 
VTC, many of these new systems use proprietary hardware and software. There are some 
however that are not proprietary. (Rettinger, 95) 

A great deal of work in recent years has shown that IP-compatible low-cost VTC 
is possible globally using the MBone. 

le MBone 

Internetworking is defined as the ability to seamlessly interconnect multiple 
dissimilar networks globally (Brutzman, 96). Physical connectivity to the Internet is a 


prerequisite to internetworking. In the past, most desktop conferencing solutions allowed 
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only two people to participate in a session. This precluded using desktop conferencing 
for meetings that required the connection of three or more locations. Today, multipoint 
technology makes it possible for a group of people to see and hear each other and 
collaborate on a task simultaneously. 

The MBone can be considered as a multipoint technology. MBone stands for 
Multicast Backbone. It is a virtual network layered on top of portions of the physical 
Internet. The MBone is used for multicast real-time applications such as 
videoconferencing and audio. 

Many related theses demonstrate that the use of the MBone can provide a quality 
desktop video conference system. The MBone applications provide the necessary tools 
for distance learning and collaborative work. (Erdogan, 96) 

In the past, the MBone technology could only be transmitted over a high- 
bandwidth physical media (e.g. T1 line at 1.5 Mbps) because it was transmitting audio 
and video simultaneously. This technology required a large bandwidth due to primitive 
compression algonthms used to encode audio and video data. Recent developments in 
MBone software applications and incorporation of sophisticated compression algorithms 
make it possible for this technology to be used over low-speed network connections. 

The MBone technology and associated protocols are becoming standardized by a 
variety of organizations, most notably the Internet Engineering Taskforce (IETF) Audio- 
Visual Transport (AVT) working group (Audio/Video Transport Charter, 96). A 


complete variety of machines and operating systems are already interoperable. 
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E ISDN AS A COMPATIBLE SOLUTION 

New applications (like the MBone tools) that require a moderately large 
bandwidth to perform properly are making standard telephone technology inadequate for 
extending a LAN. The network connectivity demand for higher bandwidth is the driving 
factor behind searching for a new technology (Wiedenhoeft, 94) (Bigelow, 95). The 
solution must not only be technically feasible but also cost effective. 

The purpose of this thesis is to investigate and evaluate the potential effectiveness 
of using ISDN for extending a LAN environment. Various forms of ISDN technology 
has been in existence for over ten years. It remains to be determined whether this 
technology has matured sufficiently over the years, and whether standards are working 
that will avoid making ISDN a proprietary solution. A past thesis made a preliminary 
evaluation of ISDN as a solution for an extended LAN and determined that the ISDN 
standards and technology were not fully developed (Bigelow, 95).’ 

In 1995, Major Michael R. Macedonia USA, a Ph.D. student at the Naval 
Postgraduate School (NPS) posted a question to the ISDN news group. He was trying to 
find out if anyone had successfully used MBone over ISDN. At the time that Major 
Macedonia posed his question, MBone applications needed more than 128 Kbps to 
perform properly. Two BRI “bonded” B-channels could not offer the required 


bandwidth. At that time, a handful of users were using ISDN for IP and MBone 


‘Bigelow’s findings are summarized in Chapter II. 


connectivity. However, the usefulness of BRI ISDN for MBone was problematic due to 
the 128 Kbps constraint. 

The ISDN issues that Bigelow’s thesis identified and the multicasting problems 
that Major Macedonia uncovered need to be re-evaluated. This thesis investigates 
whether show-stopper ISDN problems of the past are still present today. 

F, ISDN FOR THE NAVY AND MARINE CORPS 

Section B of this chapter addressed many reasons why organizations are pushing 
for connectivity outside the organization. These reasons can apply to the military as well. 

Not only 1s internetworking important in an office environment, it will become 
equally important on the battlefield for tactical reasons. We expect that the battlefield 
commander will need to rely on internetworking in order to achieve cooperative 
engagement (Nierle, 96). Previous theses have shown the need for applications to 
conform to IP (Bigelow, 95) (Nierle, 96). IP is essential to assure universal 
interoperability and hardware-independent evolution of tactical applications. With this in 
mind, information managers in the military have the responsibility to evaluate new 
technologies and find the one that bests supports the needs of the organization and 
supports IP. One such candidate technology is ISDN. 

G. SUMMARY 

This chapter addresses the need for user connectivity by extending an 

organization’s LAN and the problems to achieve it. It addresses VTC which 1s a system 


used in an extended LAN environment. Many VTCs however use proprietary hardware 
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and software which create interoperability issues. The MBone technology and associated 
protocols have been successfully used in VTC to achieve interoperability. However, the 
MBone application tools require a moderately large bandwidth (128 Kbps) to perform 
properly. 

Many technologies are emerging which are possible solutions for providing the 
necessary bandwidth to transmit the MBone application tools. The technology chosen 
needs to provide interoperability standards to enable extended connectivity and also be 
cost effective. This chapter addresses the need to investigate the current state of the 
ISDN technology and evaluate the potential effectiveness of using it for extending a LAN 


environment within the military. 


17 








IV. TELEPHONE COMPANIES ISDN DEPLOYMENT 


AS INTRODUCTION 

This chapter addresses how the Regional Bell Operating Companies (RBOCs) 
deployment of ISDN differs from RBOC to RBOC. Section B addresses the evolution of 
ISDN. Section C addresses the International Standards for ISDN. Section D addresses 
the different services that each RBOC provides. 

B. EVOLUTION OF ISDN 

Thirty years ago the entire telephone network was analog. Information was 
transported through the network as an analog signal from point to point. Computer 
information, which is digital, had to be converted first to analog before being transported 
across the network. 

During the next two decades, the telecommunications network in the U.S. went 
through a digital evolution. This digital evolution began with the advent of T-carmier, a 
digital interoffice transmission system with an analog stored program controlled switch 
(Bellcore, 85). The T-carrier allowed the phone companies to stop making analog 
connections between the central offices (COs). When a person’s voice or analog modem 
signal reaches one central office, it is promptly digitized. The digital information 1s then 
transferred via switches to the receiving central office. At the receiving central office, 
the digital information is converted back into an analog signal and continues to its 


destination point. 
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During the past decade, the concept of digital connectivity has continued. ISDN 
is a technology based on this concept. It 1s a network architecture which through 
standardization of user and network interfaces allows customer access to multiple 
communication services (Bellcore, 85). Information is transported through the network 
in digital form from the customer premises to its destination point. The network 1s 
“integrated” in that the system facilities provide end-to-end digital connectivity for voice, 
data and video services. Computers can connect directly to the telephone network 
without first converting their signals to an analog audio signal (as modems do). 

The concept of digital connectivity has begun to rapidly influence the trend 
towards more sophisticated applications that require large bandwidths to perform 
properly. The bandwidths that are required for these applications are more than what is 
allocated to an analog phone line. 

Cc INTERNATIONAL STANDARDS FOR ISDN 

The international telecommunications standardization organization which is now 
known as the Telecommunications Standards Bureau (TSB) has played a key role in 
developing standards. The Bureau was formerly the Consultative Committee for 
International Telegraph and Telephone (CCITT). 

In 1984, two types of user-network interfaces were standardized by the TSB for 


ISDN: Basic Rate Interface (BRI) and Primary Rate Interface (PRI). 
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1. Basic Rate Interface (BRI) 

The BRI ISDN connection contains three separate channels: two B channels and 
one D channel. Some documentation refers to these channels as “pipes.” The two B (for 
bearer) channels transmits the user information and are typically 64 Kilobits per second 
(Kbps) data channels. The D (for data) channel carries call-setup and signaling data (also 
known as out-of-band signaling) between the ISDN device and the phone company. It is 
not normally used for anything else. This channel is 16 Kbps. The two B channels can 
combine together to form a single 128 Kbps data channel through a process called 
“bonding.”’ The standard BRI is referred to as a 2B+D connection. The BRI ISDN 
channel is shown in Figure 4.1. (Pacific Bell, 94) 

The signaling information tells the telephone company switches what to do with 
the data that's being delivered via the B channel. This signaling information opens and 
closes circuit switches to route calls along a dedicated path between caller and receiver. 
As mentioned previously, standard ISDN uses out-of-band signaling via the data (D) 
channel. In-band signaling refers to the delivery of the signaling information being carried 
in the same channel as the user information (in the bearer channel). (Angell, 95) 

Some local telephone companies are slow to implement out-of-band signaling 
connections and use in-band signaling. The in-band signaling uses 8 Kbps in the B channel 


causing the B channel to only transmit data at 56 Kbps instead of the standard 64 Kbps. 


‘Protocols for achieving 128 Kbps transmission are addressed further in Chapter 
V. 


a 


Pacific Bell (PacBell) does not offer out-of-band signaling in the Monterey area (although 


their ISDN sales representatives say they do). 
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a Primary Rate Interface (PRI) 

Primary Rate Interface (PRI) consists of 23 64 Kbps B channels and one 64 Kbps 
D channel. It is referred to as 23B + D. One PRI line is much cheaper than eleven and a 
half BRI lines. If users need a large number of ISDN lines in one place or need a line that 
can transmit more than 128 Kbps, PRI should be used. Using one PRI line or multiple 
BRI lines is more cost effective than using a standard T1 line. 


D. REGIONAL BELL OPERATING COMPANIES (RBOC) ISDN 
DEPLOYMENT 


Dedicated digital telephone lines have been around for a long time. They are 
leased lines that operate 24 hours each day for a fixed monthly rate. There are no 
connection-by-connection usage charges associated with dedicated lines. ISDN 1s not 
considered a dedicated system. 

ISDN is an on-demand system and is treated in many ways like plain old telephone 


service (POTS) in terms of charges. Ifa person makes a local call, the local telephone 
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company charges the person for that call. If a person makes a long-distance call, the long- 
distance telephone company charges for the call. ISDN billing works similarly. Therefore 
it is impractical to use an ISDN line as a dedicated connection 24 hours a day since billing 
tariffs are not economical. 

In 1992, the Regional Bell Operating Companies (RBOCs) and network switching 
system manufactures made an agreement to provide standard ISDN services. This 
commitment is called National ISDN. National ISDN specifies the way that telephones 
and computers communicate with the ISDN network. The National ISDN agreement 
ensures that each central office switch operates in a standard way, providing a uniform 
interface to the Customer Premises Equipment (CPE). (U. S. West, 96) 

In recent years the United States has had seven RBOCs.” Each company provides 
telephone services for that region. In addition to the RBOCs, there are independent 
telephone companies (ITCs). All of these companies provide local service. Long distance 
telephone companies are called InterExchange Carriers (IC or IEC). They provide service 
between local telephone companies. With the Telecommunications Deregulation Act of 
1996, the IECs can now compete in the local market as well (S.652, 96). These 
companies operate independently which results in uneven ISDN service availability, 
pricing and service. Sometimes it is difficult to get reliable, consistent answers from these 


providers about their ISDN services. 


*Pacific Bell is merging with South Western Bell and Bell Atlantic is merging with 
NYNEX. When this happens, there will be five RBOCs instead of seven. 
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Some telephone companies are trying to make ISDN easy to use. They are 
constantly updating their office equipment to comply with TSB standards. These 
companies are using aggressive marketing strategies to sell ISDN as the latest and greatest 
in modern technology. Other telephone companies continue to be sluggish in ISDN 
implementation. They are waiting for the market to come to them. However, the 
demand for ISDN in these areas will never increase if the ISDN equipment manufacturers 
and local telephone company do not collaborate and market the product. (Angell, 96) 

i Different ISDN Services 

Although the BRI standard is 2B+D, different telephone companies offer a variety 
of BRI channel configurations. The BRI channel configuration determines the type of 
information that gets transmitted through each B channel. Therefore it is important for the 
user to know beforehand what the requirements for the ISDN line are before ordering the 
service. Ifuser needs requirements change, the channel configuration may change (and 
the phone company will charge for the change). Figure 4.2 lists the available BRI channel 


configuration options: 
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Interface Type Interface Configuration 


0OB+D D Channel Only 
1B 1B Voice 
1B 1B Data 
1B 1B Alternate Voice/Data 
1B 1B Packet Data 
1B Voice, D Packet Data 
1B Data, D Packet Data 
1B Alternate Voice/Data, D Packet Data 
1B Voice, 1B Data 
1B Voice, 1B Packet 
2B Data 
1B Data, 1B Voice/Data 
1B Data, 1B Packet Data 
1B Voice/Data, 1B Packet Data 
1B Voice, 1B Packet Data 
2B Data, D Packet Data 
1B Data, 1B Voice/Data, D Packet Data 





Figure 4.2. BRI channel configuration options. From (Angell, 95). 


Most ISDN equipment ts flexible enough to operate on any ISDN line. The local 
telephone company has special ISDN ordering operators so they can assist the user in 


determining which service is appropriate. 
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2 Different Telephone Company Switching Systems 

A switch refers to electronic facilities that route telephone traffic from one 
destination to another. ISDN service is a circuit switching system. The term circuit 
switching means that the communications pathway remains fixed for the duration of the 
call and is unavailable to other users. Electronic switching software operated on specialize 
switching computers provides the basis for the operation of ISDN. 

(Angell, 95) 

By way of contrast, the term packet switching refers to the sending of data in 
packets that are individually sent by the most efficient route and then reassembled at their 
destination. IP packets sent by a single users computers pass through the point-to-point 
ISDN connection and are then connected to a LAN, where they can be routed anywhere 
on the Internet. 

The leading digital circuit switches used by RBOC are AT&T’s SESS (Electronic 
Switching System) and Northern Telecom’s (NT) DMS-100 switches. The SESS uses 
either Custom or National ISDN 1 (NI-1) software and the DMS-100 uses only NI-1 
software. (Angell, 95) 

These switches (and their associated software) have become standard because 
compatibility between user ISDN equipment and the telephone company’s switch is 
necessary to communicate via ISDN. Therefore, when ordering ISDN service, the user 
needs to tell the telephone company the exact brand and model of the equipment that will 


be used on the ISDN line. 
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3. Inconsistent ISDN Pricing 

ISDN pricing policies are called tariffs by the phone companies. The tariff is based 
on complex cost allocations and recovery rules established by federal and state regulators.’ 
Therefore, ISDN pricing varies from one RBOC to another and from state to state. For 
example, the California Public Utilities Commission (CPUC) recently changed its order 
and related pricing rules on March 13, 1996 (Pacific Bell, 96). This provided new 
guidelines for PacBell to resell its products and services. 

The CPUC’s order moved ISDN into a competitive product category. This means 
that the product is divided into separate components (e.g. usage, monthly fee and 
installation). Each cost component is priced separately to enable the company to recover 
its expenses in accordance with regulatory rules. As a result, the various cost components 
may no longer subsidize each other. (Pacific Bell, 96) 

As a result of this order, PacBell filed its new tariff with the CPUC. It proposed 
raising the monthly fee by $8. The increase was filed because PacBell originally expected 
only 12 percent of its ISDN customers to require repeaters. It has found that 24 percent 
of business ISDN users and 30 percent of personal ISDN users are located more than 3 
miles from the central office. PacBell was not charging extra for repeaters. The cost to 
provision and maintain high-quality, high-speed digital lines in rural areas is higher than in 
metropolitan areas. PacBell’s analyses showed that their current prices would not sustain 


their ISDN service offerings. (Pacific Bell, 96) 


*Tariffs are not based on competition. 
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The total cost to receive ISDN services is dependent upon the configuration option 
chosen above, installation costs, distance charges, usage charges and a fixed monthly fee. 
Continued variation in pricing can be expected to continue as the telecommunications 
industry is deregulated, services improve and competition increases. Further reduction in 
costs for educational connectivity is likely in this rapidly changing environment. Appendix 
B shows the current tariffs and installation costs for each of the RBOCs. 


4. Joint Marketing/Alliance Agreements with the Local Exchange 
Carrier (LEC) 


In order to market ISDN better, the telephone companies and ISDN equipment 
vendors have been working together to make setting up a connection easier. Each Local 
Exchange Carner (LEC) has been forming alliances with CPE vendors that allow both 
parties to jointly sell their products. The joint selling approach focuses on delivery of a 
complete solution for a customer’s application. Under this type of program, ISDN 
services can be standardized for that RBOC area. With standardization, vendors can 
ensure interoperability of equipment. 

Several RBOCs have facilities for testing ISDN CPE and applications. The 
testing is divided into three categories: ISDN Protocol Compatibility Testing, 
Interoperability Testing and ISDN CPE “SUPER” Testing. “SUPER” testing includes 
human factors testing (Bellcore, 96). The phone companies have a list of approved ISDN 


vendors and products that work with that LEC’s switches. 
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jie SUMMARY 
This chapter addresses the evolution of ISDN and the ISDN International 
Standards. It also addresses how the Regional Bell Operating Companies (RBOCs) 


deployment of ISDN differs from RBOC to RBOC. 
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V. USER NEEDS ANALYSIS RELATIVE TO ISDN 


A. INTRODUCTION 

This chapter gives an analysis of user needs for an extended LAN relative to 
ISDN capabilities. Section B deals with the applications used in an extended LAN. In 
order to have these applications, the user needs a technology that will support these 
applications. User applications provide the driving requirements. 

Sections C through E describe what functions ISDN needs to support. 
Specifically, section C explains the Transmission Control Protocol/ Internet Protocol 
(TCP/IP) standards and the Open Systems Interconnection (OSI) reference model. The 
ISDN reference model is mapped to OSI and TCP/IP to explain how it is technically 
possible to interconnect two systems using ISDN. 

Section D explains the different functions of ISDN that cannot be directly mapped 
to layers in these well-known reference models. The different ISDN functions are 
needed to provide a standard to achieve interoperability between two systems and to 
explain how the technology can provide the necessary bandwidth to run the user’s 
software applications. 

Section E describes multicasting which is an inherent requirement for an extended 
LAN environment. MBone technology is an example of a network that requires 
multicasting. The MBone application tools are selected to test whether ISDN supports 


multicasting. 
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Figure 5.1. Analog vs. ISDN. From (Pacific Bell, 94). 
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The combined voice and data capabilities of ISDN can support a broad range of 
applications. However, unlike traditional POTS phone lines which all work alike, ISDN 
lines must be configured to the user’s applications. For example, the setup and 
equipment for a LAN-extension environment is different from the setup and equipment of 
a room-sized video teleconference (VTC) application, or an environment where the user 
is carrying on simultaneous voice and data traffic. This thesis only covers IP-based 
applications which extends the user’s LAN environment.’ 

1. Telecommuting 

Telecommuters are employees who work from home part or full time. The idea 
of telecommuting using ISDN 1s to transport most of the functionality of the office to the 


home. Typical office functions pertinent to the use of ISDN are included in Figure 5.2. 


High-speed access to the user’s LAN and file servers. 
Fast interconnections to other company LANs or hosts, remote systems. 
Interconnections to other networks especially the Internet. 


Access to and the ability to use electronic mail (e-mail). 


Teleconferenced meetings using Multicast Backbone (MBone) applications. 





Figure 5.2. Office functionality needs for telecommuting. 


'The ISDN line used for this extended LAN is a 2B+D line for data only. 
Different line configurations are explained in Chapter IV. 
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In order to achieve this extended LAN, the user needs a technology that can 
support more bandwidth than a 28.8 Kbps modem provides. Bandwidth means data 
transmission capacity. The greater the bandwidth, the more data can pass through the 
media in a given amount of time. Many new applications require a lot of bandwidth to 
maintain a data transfer rate acceptable to the user. The demand for this bandwidth by 
applications is the driving force in finding alternative technological solutions to analog 
telephone lines. (Wiedenhoeft, 94) 

A POTS line can support a 28.8 Kbps modem which can provide certain office 
functions adequately (e.g. e-mail, file transfer, slow Internet access). However, as 
graphical user interfaces in Web browsers (e.g. Netscape) become the standard interface 
on the Internet, users demand higher-speed connectivity to the Internet. It 1s not practical 
to use 28.8 Kbps modems to retrieve large graphics, audio or video files over the Internet 
because the modem speeds are slow. The user will find that it will take a long time to 
upload applications or download information. Exceptionally long transfers also run the 
risk of losing the entire transfer if connection reliability is poor. Since personnel costs 
and productivity are paramount, it is easy to understand why proper network support is 
crucial. 

Desktop VTC is another example of a multimedia application that 1s needed in an 
extended LAN environment and requires a lot of bandwidth.7, VTC depends on the 


ability to communicate from one-to-many or many-to-many hosts. Current studies show 


* VTC is addressed as a need for an extended LAN in Chapter III. 
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that the MBone can provide an economically feasible desktop VTC system (Erdogan, 96) 
(Rettinger, 95) (Tiddy, 96). With sophisticated compression control algorithms, the new 
MBone tools can run effectively over a 128 Kbps bandwidth. MBone also requires 
standard IP connectivity to support multicasting. This thesis tests if it is technically 
feasible to use ISDN technology to support a desktop VTC system. Multicasting and 
MBone application tools are explained further in section E. 
e. ISDN REFERENCE MODEL 

Both TCP/IP and OSI explain how computers of all sizes, from many different 
computer vendors running totally different operating systems, can effectively 
communicate with each other. No matter how different, two systems can communicate 


effectively if they have the following attributes in common (Figure 5.3): 


Functions: they implement the same set of communications functions. 


Organization: these functions are organized into the same set of layers. Peer 


layers must provide the same functions, but note that it is not necessary that 
they provide them in the same way. 


Protocol: peer layers must share a common protocol. 





Figure 5.3. Common attributes for communicating systems. From (Stallings, 88). 


Each model is based on functional layers to define the communication capabilities 
needed to enable any two machines to communicate with each other. A protocol is a set 


of conventions to describe the rules of communications between entities in a 
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communications environment. Communication is achieved by having corresponding 
entities in the same layer in two different systems communicate through protocols. 

The OSI is the most widely discussed network reference model but is of little 
practical interest since it is not widely implemented. The TCP/IP protocol suite, on the 
other hand, is widely implemented because of the ubiquitous nature of the Internet. 
Although ISDN does not directly depend on TCP/IP or OSI, the two models can be used 
to map out and illustrate ISDN’s protocol architecture to explain how to connect ISDN 
devices and higher-layer services. The TCP/IP and OSI models are presented first so that 
they can be compared with ISDN’s protocol architecture. 

1. TCP/IP 

Networking protocols are normally developed in layers, with each layer 
responsible for a different facet of the communications. This division of labor is to 
provide clarity and interoperability among software components. TCP/IP is certainly the 
most widely implemented set of protocols because of the Internet. It is normally 
considered to be a 4-layer system as shown in Figure 5.4. This protocol suite defines and 
routes datagrams across the Internet and provides connectionless transport service. The 
TCP/IP protocol uses packet switching (i.e. routing). TCP provides reliable delivery, 


while UDP provides a best effort (i.e. unreliable) service to deliver its packets. 
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APPLICATION | rELNet, FTP, E-MAIL 


a 
_ TRANSPORT __ | TCP, UDP 


NETWORK __|IP, ICMP, IGMP 


LINK | Device driver and interface card 





Figure 5.4. Four layers of the TCP/IP protocol suite with example components. 
From (Stevens, 94). 


a. Link Layer 

The IP protocol uses the services of the link layer to accomplish the actual 
transmission along the path. This layer is sometimes called the data-link or the network 
interface layer and normally includes the device driver in the operating system and the 
corresponding network interface card in the computer. Together they handle the 
hardware details of physically interfacing with the cable or whatever type of media is 
being used. 

b. Network Layer 

The network layer (sometimes called the Internet layer) handles the 
movement of packets around the network. Data packets are encapsulated with an IP 


datagram which contains routing information. This layer is responsible for receiving or 
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ignoring incoming datagrams as appropmiate from other hosts. It also handles network 
error and control messages. Internet Protocol (IP), Internet Control Message Protocol 
(ICMP) and Internet Group Management Protocol (IGMP) are the protocols that operate 
at this layer. 

e Transport Layer 

The transport layer provides a flow of data between two hosts, for the 
application layer above. In the standardized TCP/IP model there are currently two 
different standardized transport protocols: Transmission Control Protocol (TCP) and 
User Datagram Protocol (UDP). 

TCP provides a reliable flow of data between exactly two hosts. It is concerned 
with tasks such as dividing the data passed to it from the application into appropniately 
sized packets for the network layer below, acknowledging received packets, and setting 
timeouts to make certain the other end acknowledges packets that are sent. It is also 
responsible for reordering datagrams that arrive out of order. Although individual 
packets are not constrained to follow identical routes, TCP is referred to as a 
“connection-oriented” protocol since transport layers on corresponding end hosts see a 
single reliable connection between them. 

UDP sends packets of data called datagrams from one host to the other, but there 
is no guarantee that the datagrams reach the other end. Any desired reliability must be 


added by the application layer. Thus UDP communications are often called 
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“connectionless” because their is no logical requirement for acknowledgment or 
retransmission when losses occur. 

d. Application Layer 

This layer handles the details of the particular application, which is 
usually a software process. There are many common TCP/IP applications that almost 


every [P-compatible operating system provides. Several are listed Figure 5.5. 


telnet for remote login 


File Transfer Protocol (ftp) 


Simple Mail Transfer Protocol (SMTP), for electronic mail 





Simple Network Management Protocol (SNMP) 
Figure 5.5. Example TCP/IP applications. From (Stevens, 94). 


2. OSI Model 

The OSI model is a widely referenced network software structuring technique 
also based on vertical layers. It was developed by the International Standardization 
Organization (ISO). Like the IP protocols, it provides a framework for defining a set of 
standards to describe how the communication of computers works. However it 1s not 
widely implemented in practice. 

Each OSI layer performs a related subset of the functions required to 
communicate with another system. It relies on the adjacent lower layer to perform more 


primitive functions and to conceal the details of those functions. Each layer also 
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provides services to the adjacent higher layer. The functions and capabilities expected at 
each layer are specified in the reference model. The model does not specify however, 
how this functionality must be implemented. The requirement to interface to adjacent 
layers typically provides undesirable overhead since direct communication between 
nonadjacent layers is not permitted. For clarity, a representation of the OSI model 
mapped to corresponding layers in the TCP/IP model is shown in Figure 5.6. 


Explanations of each layer follow. 


APPLICATION 
PRESENTATION 
SESSION 


APPLICATION 


TRANSPORT TRANSPORT 
NETWORK NETWORK 


DATA LINK LINK 
PHYSICAL 





Figure 5.6. Correspondence between OSI and TCP/IP models. From (Brutzman,96). 
a. OST Application Layer 
The application layer is responsible for giving user applications access to 


the network. Examples of application-layer tasks include file transfer, electronic-mail 
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services, and network management. To accomplish its tasks, the OSI application layer 
passes program requests and data to the OSI presentation layer, which is responsible for 
encoding the application layer’s data in the appropriate form. 

b. OSI Presentation Layer 

The OSI presentation layer is responsible for presenting information in a 
manner suitable for the applications or users dealing with the information. Functions 
such as data conversion, special graphics or character sets, data compression or 
expansion are carried out at this layer. 

ce OSI Session Layer 

The OSI session layer is responsible for synchronizing and sequencing the 
dialog and packets in a network connection. This layer is also responsible for making 
sure that the connection is maintained until the transmission is complete, and ensuring 
that appropriate security measures are taken during the connection. Functions defined at 
the session layer include those for network gateway communications. 

d. OSI Transport Layer 

This layer is crucial because it sits between the upper layers (which are 
application dependent) and the lower ones (which are network based). This layer is 
responsible for providing data transfer at an agreed-upon level of quality, such as transfer 
at specified transmission speeds and error rates. To ensure delivery, outgoing packets are 
assigned numbers in sequence. The sequence numbers are included in the packets that 


are transmitted by lower layers. The corresponding transport layer at the receiving end 
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checks the packet numbers (to make sure all have been delivered) and to put the packet 
contents into the proper sequence for the recipient. Finally, the transport layer provides 
services for the session layer above and uses the network layer below it to find a route 
between source and destination. 

e. OSI Network Layer 

The OSI network layer is also known as the packet layer. It is responsible 
for determining addresses or translating from hardware to network addresses. These 
addresses may be on a local network, or they may refer to networks located elsewhere on 
an internetwork. 

One of the functions of the OSI network layer is to provide capabilities needed to 
communicate on an internetwork. The layer is also responsible for finding a route 
between a source and a destination node or between two intermediate devices. It is 
responsible for establishing and maintaining a logical connection between these two 
nodes to establish either a logically connectionless or a logically connection-oriented 
communication. 

Data is processed and transmitted using the data-link layer below the network 
layer. Responsibility for guaranteeing proper delivery of the packets lies with the OSI 
transport layer, which uses network-layer services. 

f OSI Data Link Layer 
This layer reproduces, transmits and receives data packets. The layer 


provides services for the various protocols at the network layer, and uses the physical 
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layer to transmit or receive material. The OSI data link layer creates packets appropriate 
for the network architecture being used. Requests and data from the network layer are 
part of the data in these packets. These packets are passed down to the OSI physical 
layer. . 
g. OSI Physical Layer 
The OSI physical layer 1s the lowest layer in the model. This layer gets 

data packets from the OSI data link layer and converts the contents of these packets into a 
series of electrical signals that represent 0 and 1 values in a digital transmission. These 
signals are sent across a transmission medium to the OSI physical layer at the receiving 
end. At the destination, the corresponding OSI physical layer converts the electrical 
signals into a series of bit values. These values are grouped into packets and passed up to 
the local OSI data link layer. 

3. ISDN MODEL 

ISDN is used for user-to-user communications and for user-to-network 
communications. The bulk of ISDN protocols deal with the interface between the user 
site and the network over the D-channel. The protocols dealing with the B-channel are 
basically transparent to the ISDN user applications. 

The TCP/IP protocols primarily deal with network interactions above the data 
link layer. This means that IP can typically be sent using any data link and physical link 
protocols. The ISDN model can be mapped to the bottom two layers of the TCP/IP stack 


(i.e. the Link Layer and Network Layer). ISDN is essentially unconcerned with the 
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Transport and Application layers of TCP/IP because ISDN deals solely with end-point 
network access and not with end-to-end routing of Internet traffic between hosts. The 
Transport and Application Layers deal with connection management and end-to-end host 
connectivity. Applications on the host machines communicating over the network are 
expected to provide their own end-to-end services. Otherwise they rely on TCP/IP 
transport protocols (UDP/TCP) to provide such services. (Tittel/James, 96) 

The manner in which IP is transferred over ISDN is specified in (RFC 1356). The 
Experimental Results chapter in this thesis tests whether IP (in particular multicast IP) 
can run over the data and physical link of BRI ISDN. 


Figure 5.7 shows this comparison between OSI, TCP/IP and ISDN models. 
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Figure 5.7. Correlation between OSI, TCP/IP and ISDN models. 
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a. ISDN Layer I 


Figure 5.8 lists the functions of ISDN layer 1. 


Encoding of digital data 

Duplex transmission over the B-channel 
Duplex transmission over the D-channel 
Multiplexing of BRI or PRI connections 


Activation and deactivation of the virtual circuit 


Provision of power from NT1 to terminal 


Faulty terminal isolation 


D-channel contention/access 





Figure 5.8. ISDN Layer 1 functions. From (Tittel/James, 96). 


ISDN Layer 1 describes the physical connections between ISDN devices and the 
network termination device (NT1). CCITT Recommendation I.430 defines the physical 
layer specifications for the BRI channel. The PRI physical layer is defined in CCITT 
Recommendation I[.431. 

b. ISDN Layer 2 
This layer is concerned with the communications between two machines. 
With ISDN the responsibility for call setup, maintenance and disconnection between two 


machines lies with the D-channel. For this reason, Link Access Procedures (LAP-D) is 
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concerned mainly with the D-channel. LAP-D is defined in CCITT standards I.440 and 
1.441. 

LAP-D’s purpose is to provide two types of service. It must handle multiple 
terminals on the user-network side of the NT1, and it must be able to support 
communication between multiple layer 3 protocols operating on the ISDN. 

Link Access Protocol-B (LAP-B) is the X.25 layer two protocol. CCITT 
standards specify that X.25 may be used for packet-switching transmission on the D- 
channel. X.25 was in existence before ISDN standards and so LAP-B incorporated X.25 
in its standard. However there are problems using LAP-B over the D-channel and many 
authors recommend avoiding use of LAP-B in an ISDN network (Angell, 1996). 
Essentially this is a hardware design issue of little direct interest to ISDN users. 

C. ISDN Layer 3 

ISDN Layer 3 is concerned with network functions of addressing, routing 
and delivery of information. On an ISDN network, the D-channel is designated to 
perform these functions. This layer deals with signaling procedures established between 
the user network and the ISDN, call control, and access to and control of supplementary 
services.” This protocol information is carried across the network in LAP-D frames. 


(Tittel/James, 95) 


“Internal network signaling is carried out by out-of-band signaling which is 
discussed in Chapter IV. Layer 3 signaling discussed here deals with signals carried 
from the user network or terminal to the ISDN. 
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CCITT standard 1.451 describes call control procedures. X.25 is a protocol suite 
that defines operations between devices in a packet-switching network. X.25 was in 
existence before ISDN, and ISDN has incorporated the X.25 standards when dealing with 
a packet-switching network. Otherwise the ISDN network mainly concems itself with 
channel D. 

D. ISDN FUNCTIONS NOT DIRECTLY MAPPED TO TCP/IP OR OSI 

There are certain requirements for ISDN that do not have clear correspondences 

within the structure of the TCP/IP or OSI models. The most important of these aspects 


are listed in Figure 5.9. 


Multiple Related Protocols: An example of this is the use of a protocol on the 
D channel to set up, maintain and terminate a connection on a B channel. 


Multimedia Calls: ISDN will allow a call to be set up that allows information 


flow consisting of multiple quality of service types such as voice, data, 
facsimile, and control signals. 


Multipoint Connections: ISDN allows conference calls (i.e multiple 
simultaneous callers). 





Figure 5.9. ISDN requirements not directly mapped to OSI. From (Stallings, 88). 
Leading ISDN manufacturers have been collaborating on new multiple related 
protocols for bandwidth management. Bandwidth management is needed in order for 
ISDN to be a technically sound and cost-efficient solution for extending a LAN 
environment. One B channel provides a 64 Kbps bandwidth. Combining two B channels 


provides a 128 Kbps bandwidth which is acceptable to adequately perform necessary 
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applications in the LAN environment. By collaborating on protocols, ISDN 
manufacturers are trying to provide standards which will enable equipment from different 
vendors to be interoperable. Some protocols have already become an Internet standard, 
such as Point-To-Point Protocol (PPP) (RFC 1661). Others are only proposed protocols 
which are under review by the Internet Engineering Task Force ETF). Those standards 
and proposed standards which are necessary for an extended LAN environment are 
discussed in the following sections. The draft specifications for proposed standards are 
outlined in a series of documents called requests for comment (RFCs). 

1. Point-To-Point Protocol (PPP) 

Point-To-Point Protocol (PPP) is specified in (RFC 1661). PPP is a standard 
protocol for transmitting network data over point-to-point links using modems or ISDN 
links. Each end of the PPP link must send Link Control Protocol (LCP) packets to 
establish, configure and test the data link during the Link Establishment phase. After the 
link is established, PPP provides for an Authentication phase before proceeding to the 
Network-Layer Protocol phase. The current PPP authentication protocols are used to 
determine identifiers associated with each system connected by the link. (Simpson, 94) 

De Multilink Protocol (MP) 

Multilink Protocol (MP) proposes a method for splitting, recombining and 
sequencing datagrams across multiple logical data links. BRI and PRI ISDN both offer 
the possibility of opening multiple simultaneous channels between systems, giving users 


additional bandwidth on demand (for additional cost). By means of a four-byte 
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sequencing header and simple synchronization rules, packets can be split among parallel 
virtual circuits between ISDN systems in such a way that reordering of packets is 
minimized. This process of splitting and recombining packets reduces latency and 
potentially increases the effective maximum receive unit (MRU) packet size. 

(Sklower, 96) 

Once the communication link is established as addressed in the PPP section, the 
receiving system indicates to the other system that it is capable of combining multiple 
physical links by responding to multiple authentication identifiers. MP is specified in 
(RFC 1990) and is on track to becoming a standard. 

Using MP, ISDN can provide a virtual link with greater bandwidth than a single 
B channel (up to 128 Kbps). This higher bandwidth is essential to adequately maintain 
acceptable data speeds to operate applications across an extended LAN. Applications 
used in this case study to test whether ISDN provides adequate bandwidth are the new 
MBone tools (vat 4.0b2, rat 2.6a2, vic 2.8). The new MBone tools only need a 
bandwidth of up to 128 Kbps to provide adequate voice and video quality for VTC 
(Wood, 96). MBone and its requirements are addressed later in this chapter. 

a. Bonding vs. MP 

Many vendors claim that their ISDN equipment has “bonding” 
capabilities. Bonding allows for the two B channels to be effectively combined into a 
128 Kbps transmission. This is usually a hardware bonding which is not a virtual link. It 


is a proprietary implementation of MP, a non-standard kind of multilink, and 
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interoperability problems are an issue if it is not supported identically by the ISDN 
equipment at both ends. 

The Experimental Results chapter in this thesis tests whether SGI /ndy computers 
(which are ISDN capable) can achieve an aggregate 128 Kbps IP data transfer. Since 
both computers are SGI, there is no way to verify whether the bonding that 1s performed 
by the ISDN equipment is a proprietary function or one that satisfies the standard. 

3 Compression Control Protocol (CCP) 

CCP is a proposed standard which will support adding compression to ISDN 
communication to generate data transmission speeds up to 512 Kbps on a nominal 128 
Kbps BRI line.* The 512 Kbps effective rate is a 4:1 ratio over the 128 Kbps which users 
get when using MP. 

Many vendors already have a built-in compression scheme. However f the same 
(often proprietary) compression scheme is not identically supported by the ISDN 
equipment at both ends in the same way, compression will not work. The /ndys used for 
this case study have a built-in compression scheme. 

CCP will allow two devices to determine which type of compression algorithm 
each supports and then communicate accordingly. Presently vendors have not agreed on 


a standard because there are still too many compression algorithms to choose among. 


*CCP effectiveness is dependent on the type of data being transmitted. Many 
applications use compression algorithms that produce transmission data which can not be 
compressed further. 


a1 


The MBone tools are applications which already use compression schemes to 
provide low-bandwidth audio and video. Packetized data streams produced by these 
tools are not affected by the ISDN equipment’s built-in compression scheme. Most 
image formats also include native compression. Therefore, from an Internet user’s 
perspective, CCP only has a noticeable effect on plain text, HTML text and 
uncompressed data files. 

4. Other Proposed Protocols 

There are many other proposed protocols for bandwidth management under 
review by the IETF. Figure 5.10 lists a few of these protocols. RFCs and proposed draft 
RFCs for these protocols can be reviewed on the Internet. Knowledge of these protocols 
are not necessary for the purpose of this thesis and therefore will not be addressed 


further. 


BACP - Bandwidth Allocation Control Protocol gives users a way to add 
ISDN lines or channels as needed, and drop them when the extra 
bandwidth is no longer needed. (Richards, 96) 


RSVP - Resource reSerVation Protocol will enable routers to reserve 
bandwidth for time-sensitive data transmission. (Braden, 96) 


MP+ - Multilink Protocol Plus is an outgowth of MP developed by Ascend 
Corporation for bonding bearer channels. (RFC 1934) 





Figure 5.10. Proposed Standards. 
Be IP MULTICAST 
IP multicast is a protocol for transmitting IP datagrams from one or more sources 


to many destinations ina LAN or WAN which use the TCP/IP suite of protocols. The 
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basic service provided by IP multicast only applies to UDP which was bnefly discussed 
earlier in this chapter. In multicast UDP the application sends a single message to one or 
multiple recipients. The service is unreliable, meaning that erroneous packets are not 
automatically retransmitted. Thus, there is no guarantee that a given packet reached all 
intended recipients which belong to the multicast group. This type of service is suitable 
for the streaming applications usually used on the MBone. The MBone is more 
concerned with performance than reliability, particularly since automatic retransmission 
of streamed data is often undesirable. (Macedonia/Brutzman, 94) 

There are three fundamental types of addressing mechanisms in the current 
Internet Protocol (IPv4): unicast, broadcast and multicast. A unicast address 1s designed 
to transmit a datagram to a single destination. All packet transfer with a unicast address 
is inherently point-to-point. If a node wants to send the same information to many 
destinations using a unicast transport service, it must perform a replicated unicast and 
send many copies of the data to each destination in turn. The basic facility provided by 
the TCP protocol is a unicast addressing service. (Stevens, 94) 

Broadcasting is sending a single packet addressed to all hosts on a network. This 
places an unnecessary processing load on hosts that aren’t interested in the broadcast. 
Network segments and hosts can become overloaded with the large amounts of broadcast 
network traffic. Broadcast addresses are specially reserved IP numbers. 

With a multicast service, an application can send one copy of each packet and 


address it to a group of computers that want to receive it. This technique addresses 
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packets to a group of receivers rather than to a single receiver, and it depends on the 
network to forward the packets to the networks that need to receive them. For example, a 
computer can run an audio and video application and each single packet of digitized 

audio and video information generated by the application will be received by multiple 
computers. With a multicast group, each node or computer can be physically located 
anywhere. Packet delivery is provided to hosts that have subscribed to the multicast 
address of interests. 

Ik Multicast Backbone (MBone) 

The Multicast Backbone (MBone) successfully extends multicast addressing to 
the global Internet. When using the MBone tools, any host with appropriate multicast- 
capable software can establish a multicast group (also called a session) by selecting a 
multicast address and then announcing the group address and session lifetime to the 
Internet. Hosts are free to join or leave multicast sessions at any time. A single host can 
be a member of many multicast groups simultaneously. Strictly speaking, a host does not 
have to be a member of a particular group to send traffic to that group (although 
membership is usually an application requirement). When the number of members in a 
multicast group drops to zero, the group is essentially removed from the Internet and the 
multicast address is freed to be used for another session. (Macedonia/Brutzman, 94) 

This thesis uses the MBone tools to test whether ISDN supports native IP 
multicasting. Failure to support multicast is noncompliance with TCP/IP. If ISDN 


supports multicasting and two B channels can be effectively combined to provide the 
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necessary bandwidth for MBone, then ISDN can be considered as a technically feasible 
solution in extending the LAN environment. The Experimental Results chapter tests 
whether ISDN on SGI J/ndy systems supports channel combination and IP multicasting. 
F. ECONOMIC ANALYSIS 

ISDN basic rates for the standard configuration of 2B+D in the U.S. are included 
as Appendix B. Figure 5.1] 1s an example economic analysis for the NPS STL based on 
PacBell rates (Pacific Bell, 96). PacBell’s tariff is lower than the other RBOCs. These 
rates (provided to NPS in March, 1996) change periodically. New users installing ISDN 
outside the PacBell area need to reverify Figure 5.11 price quotes. 

This analysis makes several reasonable assumptions, assuming that the user has 
MBone-compatible Personal Computers (PCs) or workstations equipped with 
microphones (and optional cameras).° Therefore computer hardware costs are not 
included in this analysis. MBone software 1s free. 

PacBell installation charges are waived if the user commits to use ISDN for more 
than two years. Monthly administrative costs were determined to be zero for this case 
because a network administrator 1s needed regardless of the choice of network. In our 
case, the NPS STL already has several administrators. If both ends of the system belong 
to the paying organization, then the setup and monthly user costs need to be multiplied by 


2. 


°*Hardware requirements are addressed in Chapter VI. 
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Startup Cost: 


Line Installation: 


Single Line Installation (Business Service) $ 71 
*ISDN Basic Line Installation (125) 0 
** Hardware Costs: 
NT] 200 
ISDN PC Adapter Card 500 


ISDN Hub (optional, for up to 6 multiple ISDN lines or PRI port) 4,000 


Administrative Costs (Network Management) 
Training (PacBell application-oriented and Vendor oriented) Otes 
(tuition costs range from $500 to $1,000) 


* PacBell will waive the 125.00 installation fee if user agrees to 2 years of service 
**This analysis assumes user has workstations. Hardware costs are available at 
http://www. shoplet. com/hardware/db/905591.html 

*** System administrator did not attend any training. This thesis research provided 
requisite training. 


Recurring Costs: 





Monthly Single Line ISDN Usage Fee $26 

Administrative Costs (Network Management) 0 
Annual total per line $312 

Total Costs for one Line: $1,100 

Total Costs for ten Lines (STL plan) 7,400* 


*The cost was calculated by taking the price to install one PRI line + (monthly charge 
for PRI line x 12) + ISDN hub. $750+(220x12)+3$4,000=$7,400 


Figure 5.11. Example ISDN economic analysis for NPS Systems 
Technology Lab (STL). 
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G. SUMMARY 

The development of standards for ISDN includes the development of protocols 
for interaction between ISDN users and the network, and for interaction between one 
ISDN user and another. These protocols can be mapped against the IP and OSI reference 
models to explain why it is technically feasible to run IP over ISDN. However there are 
additional requirements for ISDN that are not directly described within the IP and OSI 
reference models. Unique features of the ISDN reference model and the ISDN protocols 
are enumerated in detail. 

Multicast is an IP standard. Failure to support multicast is noncompliance with 
TCP/IP. If ISDN is used to extend an IP network, then ISDN needs to support IP 
multicasting. If multicasting is supported and two B channels can be bonded by using 
MP, then the MBone tools can be used as a desktop VTC system in an extended LAN 
environment The technical feasibility of this assumption is tested in the Experimental 


Results chapter. 
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VI. ISDN-RELATED HARDWARE 


A. INTRODUCTION 

The combined voice and data capabilities of ISDN support a broad range of 
applications. However, unlike traditional POTS phone lines which all work alike, ISDN 
lines must be specially configured by the phone company to support the user’s intended 
applications. For example, the LAN-extension environment described in Chapter V only 
supports telecommuting functions which are concerned with IP-compatible data only. 
Therefore the corresponding ISDN line ordered is a 2B+D, data only line. The 
configuration setup for this line is different than the configuration for the user who wants 
simultaneous voice and data traffic or a room-sized VTC application. 

The actual ISDN connections for these applications have unique and incompatible 
specifications which require different CPE equipment. This chapter is concerned with 
the equipment setup for an extended-LAN environment addressed in Chapter IV. 

Section B explains an ISDN topology. It uses reference points to define the 
communication between the different devices and the parameters for the functional 
devices. Section C identifies the actual equipment used in this thesis. 

B. ISDN WIRING 

ISDN 1s a digital technology which employs essentially the same type of copper 

wires used for regular telephone service. However the wiring configurations for ISDN 


operate differently. The Electronic Industries Associations and the Telecommunications 
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Industry Association standard (EIA/TIA) for wiring analog and ISDN service requires an 
unshielded twisted-pair (UTP) cable of category 3 or above. The ISDN cable needs to be 
33 feet or less from the Network Termination device (NT1) to the ISDN equipment. 
(Tittle/James, 96) 

The demarcation point (DP) is the dividing line between the telephone company’s 
wiring and the premises wiring. This point can occur either inside or outside the 
building. If the DP is outside, the dividing line is at a junction box. If the DP is on the 
inside, the dividing line is at a terminal block. From the DP inward, the telephone wiring 
is the user’s responsibility. The demarcation point is also known as the network interface 
(NI). 

ISDN and POTS outlets look exactly alike but differ in the connection jacks: 
ISDN uses an 8-wire RJ-45 jack and POTS uses a 6-wire RJ-11 jack. Neither ISDN nor 
POTS uses all available wires. With ISDN only 4 of the 8 pins are used. Most ISDN 
documentation states that you can use the RJ-11 jack and don’t need to install an RJ-45 
jack. Such documentation claims that “the telephone company won’t tell you this and 
will charge you for the unnecessary jack” (Leeds, 1996). To avoid connector 
compatibility problems, this author recommends using the recommended RJ-45 jack. 
ISDN has too many complex issues. It is safer to use a standard that has been proven to 
work than to second guess compatibility issues with personally rewired adapter jacks. 

In this case study, the user did not have a choice in the line hookup. NPS is a 


military installation. All telecommunication requests go through NPS Base 
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Communications personnel, who contract with PacBell for the installation of ISDN lines. 
Presently there are no technical service employees at NPS Base Communications that 
are familiar with ISDN. Unfortunately, at the time of the hookup, there were no system 
administrators present to ask the PacBell serviceman questions. 

ISDN circuits are implemented by the provider as two-wire copper circuits from a 
central office within 3 miles of the user’s demarcation point. It should be noted that this 
3-mile limit is the biggest barrier to widespread delivery of ISDN service. The standard 
telephone wiring can only transmit a signal for three miles without putting in repeaters to 
extend the distance. Repeaters make the delivery of ISDN expensive. 

The RJ-45 ISDN interface is also known as a two-wire U interface, which is 
defined by CCITT as the demarcation point of the two-wire ISDN subscriber loop. The 
U interface is then connected to an NT1 device. The NT1 represents the boundary to the 
ISDN network from the end-user side. The NT] includes the physical and electrical 
termination functions of ISDN on the customer premises. The physical function of the 
NT1 device is that it provides an interface between the twisted-pair wires used by the 
telephone company in the BRI and the eight-wire cables used by ISDN equipment. This 
is called the S/T interface. The electrical function of the NT1 1s to act as the power 
source for operating the ISDN line.’ (Leeds, 1996) 

Each BRI access has only one NT1 device. A separate S/T reference point in the 
NT1 device will provide direct multipoint connection of ISDN devices. Multipoint 


configuration refers to the operation of multiple devices on an ISDN line. These multiple 


' Unlike POTS, if there is a power failure, ISDN stops working. 
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devices include digital phones, digital faxes, and integrated voice/data terminal devices. 
It is important to note that in order to run multiple devices on one line, all ISDN 
equipment must support the multipoint protocol. If any equipment only supports point- 
to-point, then no other device can be used in conjunction with it. 

The NT1 can be a stand-alone device or it can be embedded in a specific device. 
It is important to note that if the NT1 is embedded in a specific device (such as a PC with 
a remote access adapter card) it will restrict the use of the ISDN connection to that 
device. In this example, the user will only be able to use the BRI line for that PC, unless 
the PC has additional ports to connect other ISDN devices. Most documentation 
recommends using a stand-alone NT1, because as stated above, for each ISDN line there 
can be only one NT1. A stand-alone NT1 was used in this thesis. 

There are two types of devices that can connect to an S/T interface: terminal 
adapters (TAs) and terminal equipment (TE1). In an ISDN implementation, the TA 
device is a protocol converter that adapts equipment not designed for ISDN. The TA 
provides an R reference point, which lets non-ISDN analog serial data terminal devices 
(such as modems, fax machines, POTS telephones, and routers) to connect to the NT1 
device for ISDN service. Devices that require a TA are called TE2 devices. TAs are 
being phased out because more and more equipment is designed to be ISDN ready (TE]1). 
ISDN venders also market TAs that include the NT1 function as well as support non- 
ISDN devices (Leeds, 1996). Only one TE] was connected to the NT1 used in this 


thesis. 
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Figure 6.1 shows a simple ISDN hookup. The reference points in Figure VI. 1 
define the communication between the different devices and the parameters for the 
functional devices. They are consecutive letters of the alphabet chosen by CCITT to 
identify a set of standards. This enables vendors and users to refer to their equipment in 


similar terms. 
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Figure 6.1. Simple ISDN hookup. From (Beckman, 95). 


G. IDENTIFYING ISDN APPLICATION EQUIPMENT 

User application requirements drives the equipment selection process. The most 
important factor to consider is interoperability. Every ISDN connection has two ends and 
the equipment at each end (which may vary) must be compatible for communications to 
succeed. 

If the user 1s providing the equipment at both ends, buying from a single vendor 
vastly reduces compatibility problems. Single-source buying isn’t always possible, 
however, and is not an option when using ISDN to connect to an Internet Service 


Provider (ISP). In such cases, the user can obtain a list of compatible equipment from the 
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ISP. In this case study, connection to the Internet is made through the NPS connections 
and the equipment on both ends of the ISDN lines are SGI Jndy workstations. 

Some hardware features such as data compression, bandwidth on demand 
(BOND) and dial-back security, are proprietary to specific vendors. Others, such as 
password security and multichannel bonding, have defined standards that are supposed to 
guarantee interoperability. However, experience has shown that ISDN standards leave 
room for vendor interpretation. There are web sites which show many users frustrated 
because of standards that are not truly standards. A user can get this information by 
doing a web search of ISDN frequently asked questions (FAQs) or the ISDN User’s 
Group. Current links are located on Dan Kegel’s ISDN home-page (Kegel, 96). 

Each model of ISDN equipment has a different setup using different configuration 
commands. Vendors of ISDN equipment are trying to make setup easier for the user by 
having on-line manual pages and CD-ROMs which are already programmed for the setup 
procedure. However as noted in the Experimental Results chapter, the setup procedures 
are not always what this author would call user idiot-proof. Even the experienced 
administrator finds it difficult to interpret the commands of the on-line setup or the 
instructions of a manual. After many frustrating hours trying to configure the equipment, 
the user often has to resort to vendor technical representatives for information. 

Another important problem diagnosis action it to call the phone company to 
ensure that the ISDN line is working properly and the phone company ISDN switches are 
configured properly. This too can be a trying experience because it may take a couple of 


days for the representative to call the user back. When they do call, technical 
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representatives cannot see or directly diagnose the problem over the phone line. 
Therefore correcting the problem 1s sometimes a best-guess effort and finding the 
solution often becomes a hit-or-miss trial. These issues are painstakingly documented in 
the Experimental Results chapter. 

1. NT1 

A Motorola NT1D 1s the Network Termination device (NT1) that was used for the 
case study. It costs about $200 and includes the standard two S/T-interface ports. It was 
purchased through the DoD procurement system as a credit card purchase. Figure 6.2 


shows an NT1D. 





Figure 6.2. Motorola NTID. 


The Motorola NT1D is designed for the ISDN basic rate communication system. 
As shown 1n figure 6.1, it installs between the Central Office (CO) U interface and the 
Customer Premise (CP) S or T interface. Both point-to-point and point-to-multipoint 


configurations are supported. This case study only used the point-to-point configuration. 
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There are six light-emitting diodes (LEDs) on an NT1. Each LED indicates that 
the NT1 is performing a certain function. Figure 6.3 explains the functions of the six 
LEDs on the front of the NT1. Figure 6.4 shows a closeup snapshot of the rear panel of 
the Motorola NT1. The rear panel houses (from left to right) the power jack, one four- 
position dip switch for terminating resistor selection, two jacks for either an S or T 


interface to the CP equipment, and one U jack for connection to the CO. 
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LED 


SC (Sealing Current) 


ACT (Activity) 


LB (Loop Back) 


LP (Local Power) 


RP (Remote Power) 


RPR (Remote Power 
Reversed) 


DESCRIPTION 


When on, this LED indicates the ISDN switch has 
bounced back a termination test voltage from the NT1D. 


When on, this LED indicates that a link between the 
terminal equipment and the ISDN switch at the phone 
company via the NT1D has been established. 


If a disruption occurs between the U-interface and the 
ISDN switch, this LED flickers. 


If a disruption occurs between the S/T- interface and the 
Terminal equipment, this LED blinks once per second. 


If a disruption occurs on both U- and S/T- interfaces, 
this LED goes off. 


When on, this LED indicates the ISDN switch has sent a 
2B+D loopback command to the NT1D. 


When on, this LED indicates the local AC power is 
active. 


When on, this LED indicates the power at the remote 
site is functional. 


When on, this LED indicates the power at the remote 
site is not functioning properly. 





Figure 6.3. Functions of the LEDs on the NT1D. From (Angell, 1995). 
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Figure 6.4. Closeup snapshot of rear panel of Motorola NT1D. 


a. NT1 Hookup 

To connect the NT1, the supplied U cable inserts into the U jack on the 
NT1 and the opposite end connects to the ISDN wall jack. Similar cables are used to 
connect the S/T jacks to the designated TE] or the TA (R interface). In this case, the 
NT1 was connected to an SGI /ndy workstation which is ISDN capable. 

Ze Terminal Adapters 

There are two types of remote access devices that will connect to a PC: a bus 
adapter card and a stand-alone unit. The bus adapter cards are cheaper than the stand- 
alone solution. Bus cards use the PC bus configuration to communicate from the user’s 
PC to the terminal adapter. The cards support Ethernet or serial communication. 

A stand-alone ISDN bridge looks like a standard modem and requires a LAN 
adapter in the PC. A bridge connects separate physical networks into a single logical 
network that behaves as though it were a single physical network. The PC only 
communicates via Ethernet to the ISDN bridge. The Ethernet card connects to the ISDN 


bridge via thin Ethernet coaxial cable or an RJ-45 cable. (Angell, 1995) 
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The stand-alone ISDN bridge is a TA which connects the R interface to the S/T 
interface. In this case study, ISDN capable workstations were used which had the bus 
adapter cards. An R interface was not needed. 

3: ISDN-Capable Workstations 

Originally the NPS STL ISDN connection plan was to connect an SGI /ndy 
Presenter named baby.stl.nps.navy.mil (baby) remotely to the graphics lab network in 
Spanagel Hall via ISDN. SGI /ndy Presenters always include an ISDN interface. baby 
was connected to an SGI /ndy workstation named rambo.cs.nps.navy.mil (rambo). rambo 
is hooked up to a different Ethernet LAN as well as to a different ISDN connection. 

To avoid sharing conflicts with other students and instructors over baby, it was 
decided half way through the testing to hook-up and configure an SGI /ndy workstation 
in the STL for ISDN. The workstation used 1s a standard /ndy named 
steel. stl.nps.navy.mil (steel), also equipped with a video camera and microphone. 

4. Video Conferencing Equipment (MBone) 

Figure 6.5 shows how two computers can be connected together using ISDN and 
have a desktop VTC. The only hardware needs for MBone applications is a video 
camera that sits on top of the PC and a microphone. As stated above, the /ndy 
workstations are equipped with a camera and microphone. Video cameras are only 
needed for sending video, since generating received networked video is performed in the 


software. 
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gure 6.5. Desktop video systems. From (PacBell, 94). 


SUMMARY 
The actual ISDN line connections used for ISDN applications have unique and 
incompatible specifications which require different equipment. This chapter 1s concerned 
with only the equipment needed for the LAN extension environment addressed in 
Chapter V. It describes hardware considerations for communication between the 


different devices and the functions of those devices. 


Vil. EXPERIMENTAL RESULTS 


A. INTRODUCTION 

The area of focus in this thesis was to determine if BRI ISDN can support TCP/IP 
protocols, especially bonded channels and native IP multicast. In theory, TCP/IP deals 
with network interactions above the data link layer of the OSI model. Therefore IP can 
run over any data link and physical link protocols. ISDN protocols are mainly concerned 
with the data link and physical link. Standards require that multicasting be capability of 
an IP network. This chapter tests whether it 1s technically feasible to perform native IP 
multicasting over ISDN, so that ISDN is a “true” IP network extension technology. 

Section B addresses the initial plan of attack for installing an ISDN line and 
attempting to run an MBone demonstration. Section C addresses how the workstations 
were configured to run ISDN. Section D addresses test results once the workstations 
were configured. 
B. MBone DEMONSTRATION 

Part of the experimentation was to use ISDN to connect to a host site in France. 
This test was intended to determine whether the ISDN standards were world-wide or 
nation-wide. The Fifth Annual World Wide Web Conference was to be held on May 7, 
1996 in Paris France. The conference was being transmitted using the MBone. The 


objective was to telecommute to France and get on the Internet using that connection. If 
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the ISDN standards were just nation-wide, we would telecommute to a local site and get 
Internet access. 

There were two weeks to get a line installed and to test the feasibility of using 
MBone tools over ISDN. Initially a line was to be installed in the STL in Root Hall at 
NPS. Base Communications had ten ISDN lines available for data that no one was using. 
An ISDN jack and line was requested to be installed in the STL in order to be connected 
to one of the available lines. 

The STL had a portable SGI Jndy Presenter named baby that was never 
previously used for ISDN. The graphics lab in Spanagel Hall at NPS had an /ndy 
workstation named rambo that was already connected to ISDN as well as being 
connected to the Ethernet LAN. It was decided to hook baby to ISDN to determine if it 
was ISDN capable and have it communicate via ISDN with rambo. Once baby was | 
telecommuting with rambo, the MBone tools would be tested. Then if everything 
worked, a point of contact in Paris would be established for a trial run before the 
conference. 

A work request to have PacBell come to NPS and install the jack and line was 
generated and hand carried through the administrative chain of command. This was done 
to shorten the wait time in the processing queue and to get NPS Base Communications to 
make the ISDN line request high priority. 

NPS Base Communications was unable to satisfy the request to install a jack and 


line because of the short time constraint. It would take two-three working days for 
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PacBell to come in and install the line. There are however other existing ISDN lines at 
NPS that are used to transmit data. One line was in an office in Spanagel Hall that was 
unused. The line was connected to an ISDN jack but did not include an NT1. The 
original work request was modified to read “connect an available ISDN data line in NPS 
Base Communications to Spanagel Hall, office 402B.” NPS Base Communications was 
able to satisfy this second request.’ 

The MBone demonstration of this conference over ISDN did not take place. This 
failure was particularly disturbing because it was intended to serve as a backup to the 
school’s primary MBone connectivity. When this primary MBone link went down 10 
seconds into the NPS presentation on the distributed panel, no backup ISDN connectivity 
was available. Rather than NPS discussing future uses of the MBone, NPS demonstrated 
technical failures before a global audience. This performance is unsatisfactory. 
(Brutzman, 96a) 

The major reason why the MBone demonstration over ISDN did not work was 
because of the lack of technologically proficient personnel at NPS. Initially the line in 
Spanagel 402B could not be activated. The system administrator for the STL tested the 
setup and the ISDN equipment configuration for two days before giving up and asking 


NPS Base Communications to test the ISDN line. In order to get technical support from 


'The first work request eventually had to be rewritten and resubmitted in order to 
get an ISDN line for the STL for future, related work. 
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PacBell, Base Communications has to initiate the request which causes additional time 
delays. It took two days for NPS Base Communications to contact PacBell.’ 

It was explained by NPS Base Communications that the ISDN switch at the 
Central Office (CO) can determine whether a line is being used or not. It pings the NT1 
to verify that it is activated. If there is no NT1 attached to the line or the NT1 is powered 
off, the ISDN switch will turn the connection off. The office in Spanagel Hall had a line 
and ISDN jack but was never connected to an NT1. Apparently this caused the CO 
switch to turn off the line. 

NPS Base Communications personnel are not currently knowledgeable about 
ISDN and therefore thought that the activation of the existing line was an internal job 
rather than a job for PacBell. Therefore the hook-up of the ISDN line was not properly 
performed. 

Although the window of opportunity was closed for this MBone event, we 
decided to continue setting up an ISDN line in the STL to determine whether it was 
technically feasible to use MBone over ISDN. The scope of the investigation was 


narrowed to include only nation-wide protocol implementations instead of world-wide 


“It is noted that the request to Base Communications for assistance was informally 
done. Normally a work request needs to be generated before Base Communications 
performs any work. This would have taken an additional 1-2 weeks to route. Base 
Communications allowed this job to take priority because of the time constraint of the 
conference and the fact that it was thesis related. 


*This is Base Communications explanation of the problem with the line. A STL 
system administrator never got to talk with the technical representatives from PacBell 
and so this theory was not verified. 
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protocol implementation. Once ISDN was installed, baby would connect remotely to 
rambo to test MBone operability. 

When the ISDN line was eventually installed in the STL, there was no prior 
notification by NPS Base Communications and therefore no STL system administrators 
were available to ask questions or to watch the installation. This was frustrating because 
the network administrator’s responsibility is to support and maintain new technology and 
equipment, but they were not given the tools or knowledge with which to do it. No 
information was received from PacBell or NPS Base Communications explaining the 
BRI channel transmission capacity (64 Kbps or 56 Kbps), switch type or software used 
by PacBell. This information is necessary to properly setup the ISDN equipment. These 
problems are exhaustively documented here because we believe they are commonplace 
and a frequent impediment to proper ISDN operation. 

To avoid sharing conflicts with other students and instructors over baby, it was 
decided to hookup and configure another SGI /mdy workstation in the STL for ISDN. 
The workstation is named s/eel. stl.nps.navy.mil (steel). 

c. SETTING UP WORKSTATIONS 

1. ISDN User’s Guide 

SGI Indy workstations come with online help manuals called IRIS InSight. The 
ISDN User’s Guide is one such help manual. It provides information about setting up an 
Indy ISDN connection. A copy of this guide is available online at 


http://www.ngonet.ee:88/SGI_EndUser/ISDN_UG. 


fis 


De Phone Company Services 

The user needs to order 2B + D for circuit-switched data only.* The user does 
not want X.25 (packet-switched data) or voice-related service. Any other switch 
configuration will not get 2B channels to bond properly. 

As mentioned in Chapter IV, the user needs to know which type of switch 
hardware and switch software the phone company uses. Depending on the type of 
switch, the user may need a Service Profile Identifier (SPID). This is an alphanumeric 
string that uniquely identifies the service capabilities of an ISDN terminal. The SPID is 
an identifier that points to a particular location on the telephone company’s CO switch 
memory where relevant details about the device are stored. 

As mentioned earlier, there was no NPS system administrator present to obtain 
information during the PacBell line installation. Representative documentation was 
received from the system administrator in Spanagel Hall who set up rambo with ISDN. 
That documentation indicated that PacBell used Custom software which does not require 
a SPID for setup. Therefore, it did not appear necessary to obtain any information from 
the phone company. 

3. UUCP, PPP and ISDN Software 

UUCP, PPP and ISDN software are all needed for Jndy ISDN connections and 
superuser privileges are required to install them on workstations. UUCP software is a 


part of the Irix operating system software but it is not installed by default. VUCP, PPP 


*Various circuit-switch line configurations are addressed in Chapter IV. 
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and JSDN software are located on the main SGI software CD. To install the software on 
an SGI workstation, see instructions in “Setting up the ISDN software” in IRIS InSight 
help manuals. 

4. Configuration Files 

steel is connected to the fiber distributed data interface (FDDI) backbone on 
campus as well as ISDN. For this case study, stee/ was to represent a user’s home 
computer which would not be connected to a fiber network or any other network. 
Therefore, steel would have to be physically disconnected from the network and the error 
messages informing the user that the cable was disconnected had to be suppressed. A 


startup script was created to do this. The scnpt was as follows: 
/usr/etc/ifconfig xpi0 down 
ed /ete/re2.d 


In -s ../init.d/isdn.no_ ethernet s3lisdn.no_ethernet 
(All typed on one line) 

It was subsequently decided not to disconnect stee/ from the fiber network 
because stee/ could not be dedicated only to this case study. The experiment continued 
using steel on two simultaneous networks: FDDI and ISDN. 

To set up ISDN there are several additional files to configure. The following 


configuring process is also found in the online help manual. 


Jal 


a. /etc/hosts File 

All names and IP addresses corresponding to remote hosts and local 
machines are placed in this file because a Domain Name Server (DNS) is not being relied 
upon. Remote host rambo and its address was put in this file as follows: 
131s L2QiieA'O rambo.cS.nps.navy.mil rambo 

b. /etc/configisdnd. options File 

In this file, the software type which is provided by the telephone company 
is identified to the ISDN daemon. The ISDN daemon is /usr/etc/isdnd and is used with 
Point-to-Point Protocol (PPP) when an Indy 1s accessing another system over the ISDN 
line. The file includes several lines of information that tell the user how to edit the file 
correctly. Each line starts with a pound sign (#) to indicate that the line is a comment. 
The user removes the pound sign (#) from the line in the file that corresponds to the 


correct switch software type. In this case, the pound sign was removed from the line: 
Sie ES 


This command line was chosen because as stated earlier the documentation received from 
the system administrator in Spanagel Hall indicated switch software was Custom. 
Once this is done the ISDN software can be turned on by the root superuser by 


typing: 


/etc/chkconfig isdnd on 
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e /etc/ppp.conf File 

For each system, the user must supply three lines of information that 
include the host name of the system, and the name and password of the user login 
account on that system. A static network route is also requested using add route. Each 


entry is as follows: 

<host name> send_username=<user name> 
send_passwd=<password> 
add_route 

Thus for steel the /etc/ppp.conf file read: 

rambo send _username=baby 
send passwd=l1rmkam 


add route 
outdevs=2 (This line will be explained in a later section) 

The static network route is used when the user wants the datagrams to be routed 
solely through the ISDN line. The routing daemons are turned off. The routing daemons 
used on the NPS systems are the programs routed and gated. 

If the user wanted both the ISDN and the fiber network running simultaneously, 
the routing daemons are configured differently. The add_route line in this file 1s 
removed. Ifthe static route and the routing daemon are used at the same time, routing 1s 
be disrupted and the remote system will not be reached. A detailed description of these 


considerations can be found on the online IRIS manual pages. 
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d. /etc/uucp/Devices File 
It needs to be defined in this file what device files are being used. The 


format is as follows: 
ISDN isdn/modem_b1-38400 direct 


ISDN isdn/modem_b2-38400 direct 

é. /etc/uucp/Systems File 

The User’s Guide recommends making a backup copy of this file in case a 
default version 1s needed in the future. The permissions on the onginal file need to be 
changed by the root superuser so the file can be edited. The following information needs 


to be added for each system in the following format: 


<Host name> Any ISDN 38400 “” “" ISDNCALL[<rate>] <phone 
no>CONNECTED 
(All typed on one line) 

The <Host name> is rambo. Any refers to any time to place a call. ISDN refers 
to the device type. 38400 no longer has any meaning. At one time, 38400 represented 
transfer speed. Now it is filler input and remains a required entry. The rate refers to the 
rate at which the connection will transfer data. In this case 56 was used. The line ends 
with the word CONNECTED. It is important that there is a space between each item in 
each line. That is, leave a space after Host name, Any, ISDN, 38400, both sets of double 


quotes, and phone number. The final entry appears as follows: 


rambo Any ISDN 38400 “” “" ISDNCal1[56]2005 CONNECTED 
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> steel Needs Access To rambo 

The last line of rambo’'s /etc/ppp.conf file should read: 
_ISDN_ INCOMING reconfigure 
This is needed to give steel access to rambo. 

6. Restart 

When all editing is complete, the system needs to be restarted so the above 
changes can be recognized by the operating system kernel. 
D. TURNING ON THE ISDN CONNECTION 

Once the system is restarted for the configuration file changes to take effect, only 
the administrator who has superuser privileges can turn on and test the connection. A 
shell window was opened up and the test began. The administrator tried to make the 
ISDN connection between steel and rambo by typing: ppp -r rambo. whet several 
seconds, if successful, the connection is established and ready to use. The user sees a 
message similar to the following when a connection is made: 
ppp[3001]: rambo IPCP1: ready 131.120.7.116 to 131.120.7.49 

1. ISDN Connection Fails 

The first attempt (as well as numerous other attempts) ended unsuccessfully. The 
Output message above which acknowledges a completed connection was never displayed. 
To verify that the remote system had accepted the password and was running ppp, 


another shell window was opened and the following command was entered: 


8] 


netstat -C. This command showed the status of the different network ports. The 


results were unsuccessful and inconsistent. Sometimes ecO was up and sometimes the 


ppp0 connection never appeared.’ A successful report will look something like 


Name Mtu Network Address 

xpid 1500 L3 di Ow. PII 20 47S 
eee 
224.0.0.4 
Bf Ol) oc. 

ec0* 

100 8304 ney ee.) . Oramee 

pppo Sow (pt-to-pt) Toe. wells 
2280). Oe 


rambo was pinged from another system that was connected via FDDI. It was 
determined via FDDI and Ethernet that rambo was up. The system administrator for the 
Graphics Lab in Spanagel Hall was called to ask if the ISDN line on their side was 
working. It was. 

A confidence test on stee/ was then performed to make sure that the problem was 
not with the connection between the NT1 and the TE]. Information on how to mun a 
confidence test can be found in the InSight User’s Guide. The notifier confirmed that the 
ISDN connection was ready to use and that the problem was not with the CPE or the 


NTI. 


>The connection is down when a * is displayed after the network port. 
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Testing continued to try and determine which file on sfee/ was not configured 
properly. Then another shell window was opened and the following command was 
entered: ISDNstat. /SDWNsiat reports the progress of the call. The call to rambo was 
placed again. Both B channels were idle. It showed that B1 channel would dial, connect, 
disconnect and then be idle. No diagnostic messages were provided during these failures. 

Another window was opened and ISDN was stopped and restarted. The 
commands for this 1s as follows: 

Sse rer AsdndaVstop 


/etc/killall ppp 


/etc/init.d/isdnd start 

Because of our lack of experience with ISDN, the system administrators were not 
confident that the configuration was set up properly. They continued to search for 
answers within the confines of the ISDN equipment. It never occurred to anyone to 
check with PacBell on the line itself. 

Another test was performed to obtain more error status information. This was 
done by typing the -d flag after the command ppp -r rambo. Additional -d flags 
produce more information. SGI /ndys allow up to eight different -d flags to the ppp 


command line to display additional information.° A printout of status information is 


°Additional -d flags introduces security problems because passwords are 


displayed. 
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attached as Appendix C. The printout was given to the Graphics Lab system 
administrator in Spanagel Hall to evaluate. 

After many weeks of ISDN working periodically and failing without reason, NPS 
Base Communications was contacted. The supervisor stated that PacBell was not using 
Custom but SESS National ISDN 1 (NI1). SPID numbers were required for 
configuration of this ISDN software. The supervisor stated that both bearer channels 
needed a SPID number. If this was true, then /etc/config/isdnd. options file had to be 
changed to reflect this software and the SPID numbers. NI] is the switch software and 


the command line 1s: 


Sreeviele =o <SPIDI> -S <SPID2> -n elt -2--eZe 
The SPID numbers are the ISDN phone number with 01 at the beginning and 0 at the 
end. Each B channel has a SPID number. PN numbers are the 7-digit phone numbers. 


Therefore for the STL ISDN connection, the /etc/config/isdnd. options file now reads: 


=~) -S70165661280 -S Cis6566128 -n@eSeoizse- nm GoccolZs 

Diagnostic messages stated that it could not identify SPID. NPS Base 
Communications was contacted again and a request was made for PacBell to check the 
switching software. A Base Communication technician came to Root Hall and checked 
the line and determined it was working properly. The PacBell representative told NPS 
Base Communications that the switch for Monterey was actually a SESS Custom switch. 
The configuration was changed back to the orginal to reflect Custom software. 

The ISDN connection continues to work intermittently. It has not been resolved 


as to what the problem is. The lines were tested by NPS Base Communications and they 
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passed. No errors in transmission were noted. The NT1 was replaced with another NT1 
to determine if it was a local hardware failure. The connection came up the first time and 
failed several times after, eliminating the NT1 as the cause of failure. We still have not 
identified the cause of these intermittent ISDN line failures. 

2: Testing MP 

The /ndy supports a nonstandard method for optimizing connection speed and 
does not use the MP standard. In order to bond two B channels, the /etc/ppp.conf file 
needs to be amended. The following line needs to be added: outdevs = 2. This 
command sets the maximum number of parallel serial lines that will be used. 

When an ISDN connection between rambo and steel was made successfully, 
transmission speeds were tested. This test simulated remote users downloading files 
from their network at work. A new shell window was created and J/SDNstat was run to 
get the status of the two B channels. 

Initially the JSDNstat window only showed the B1 channel connected and the B2 
channel idle. A 1.2 Megabyte (MB) uncompressed executable file was transferred from 
steel to rambo. ISDNstat window showed that the B1 channel was transmitting at 54-56 
Kbps. The file was transmitted again using ftp. ftp showed that the transmission was 
closer to 85 Kbps. If it were not for the JSDNstat window, a user will likely think 2 
channels are connected because of the fast transfer time (>56 Kbps). In reality ppp 
software has a built-in compression algorithm which compressed the file on-the-fly. The 


debugging script shows that on-the-fly compression is taking place rather than bonding 
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two channels. The test was done two more times and the results were consistent with the 
first. .This test therefore showed that an effective throughput of 85 Kbps was possible on 
a single B channel. 

The system administrator from the STL in Root Hall contacted the administrator 
in Spanagel Hall about the two B channels not bonding. Because NPS has a maintenance 
agreement with SGI which identifies one point of contact for all of NPS dealing with SGI 
equipment, the administrator in Spanagel Hall is the only individual who can request 
technical assistance from SGI. The inexperienced ISDN administrator from STL has to 
explain the problem to the inexperienced ISDN administrator in Spanagel Hall who in 
turn will explain it to the SGI technical representative. Theoretically a solution is 
provided. In practice this process is time consuming and inefficient. Following SGI 
technical support recommendations, an SGI operating system software patch was 
installed that fixed the bonding problem (SGI Irix 5.3 patch 841). Both B channels then 
connected and similar throughput tests were performed as before. A 3.7 MB 
uncompressed executable file was transferred from steel to rambo. The JSDNstat 
window showed that both B channels were connected and that they were transmitting 110 
Kbps. The ftp command showed that the effective transfer throughput was approximately 
164 Kbps. Again the faster-than-maximum speed was due to the on-the-fly 
compression/decompression in the ppp software. 

The next step was to precompress the file so that there would be no compression 


in the transmission. The 3.7 MB executable file was compressed to a 1.2 MB file. The 
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[SDNstat displayed that each channel was transmitting at 54-56 Kbps. The results were 
again verified by using the ftp command, which recorded an effective throughput of 105 
Kbps which corroborated what /SDNstat was reporting and confirmed that further on-the- 
fly compression was infeasible. 

3. MBone Testing 

Many issues came up when trying to perform multicasting across ISDN. The first 
issue was creating a tunnel from rambo to steel. The multicast routing daemon mrouted 
insists that there be more than one virtual interface (vif) before it runs. A vifis either a 
real physical interface or an encapsulated multicast tunnel. Otherwise mrouted can only 
send the multicast packets out on the same interface as they came in on. mrouted 1s just 
like a regular router, it takes packets from one interface and sends them out on another 
interface. 

The problem is that the pppO interface doesn’t come up or even exist until ppp 
runs. Setting up the ppp “interface” is one of the things that the ppp command does. 
Therefore, a vif does not exist prior to ppp running. The pre-tunnel error message is 
Appendix D. The solution to this problem was to add a tunnel. The only thing this did 
was add a vif which allowed mrouted to run. 

Another multicast issue concerned routing. stee/ is dual-homed with FDDI which 
has multicast on it. When the multicast tools were run, the session directory came up on 
the fiber connection and not on the ISDN. We did not want to change the routing 


daemons (gated and routed) because we were not familiar with ISDN and did not want 
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the ISDN line to fail. Therefore, in order to test multicast running across ISDN and not 
fiber, stee/ would have to be disconnected from the fiber backbone. We did not want to 
disconnect stee/ (for other reasons) so it was decided to use baby for this part of the test. 

A session directory (sdr) was established on baby. rambo could not see the 
advertised session. The audio and video tools (vic and vat) were used. Nothing appeared 
on vambo’s monitor, but JSDNStat indicated that the two B channels were connected and 
that rambo was receiving data at 110 Kbps. 

It was concluded that the ISDN line was configured correctly and that it was 
transmitting and receiving properly. The reason why the session directory was not being 
advertised on the Internet must be due to an MBone configuration problem which was 
above the level of the system administrator. 

Technical support at SGI reported that there is a bug in the ppp software. 
Therefore, the ppp software does not support multicasting. This information is contrary 
to what a user from the MBone User’s list had reported. The user said that he 1s using 
SGI with Ascend products to run MBone successfully. It is possible that this original 
user employed a unicast tunnel for MBone connectivity rather then passing native 
multicast IP packets. 

i SUMMARY 

This chapter discusses the tortured methodology of how the STL in Root Hall got 

an ISDN line. It discusses the setup of the hardware and software. It also discusses the 


results of the ISDN multicast experiments and possible reasons why these experiments 
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failed. The results of the experiment determined that SGI /ndys have a proprietary 
solution to MP and if the machines at each end of the ISDN connection are /ndys, then 
speeds of over 110 Kbps (without compression) can be achieved. Native multicast 
support was not successfully demonstrated. ISDN line reliability is intermittent despite 
exhaustive troubleshooting. 

This chapter also documents the frustrations of a proficient system administrator 
who is inexperienced with ISDN technology and has no available means to get timely, 
accurate or consistent answers to questions dealing with this new technology. We 
believe that such difficulties are common based on widespread unfamiliarity with ISDN. 

ISDN is still point-to-point. Multicasting with ISDN appears to be unsupported, 
at least by SGI hardware and software. The technical representatives for the ISDN 
equipment claim to have bugs in their ppp software that prevents it from performing 


multicasting. However some MBone users claim it can be done (Appendix E). 
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vol. CONCLUSIONS AND RECOMMENDATIONS 


A. INTRODUCTION 

Installing and using a new technology can become quite an arduous task, 
especially if a new user does not have a technical background. Section B discusses the 
issues surrounding the failure of extending LAN connectivity using ISDN. Section C 
presents the results of this case study. Section D discusses recommendations to resolve 
these issues. Section E presents recommendations for future work. 
B. INSTALLATION ISSUES 

It is difficult to obtain technical help because ISDN support crosses too many 
organizational boundaries. PacBell sells the user the ISDN line. The technician that 
installs the line may not know anything about the technology itself except how to install 
the line and how to test that it is connected. The information about the technology is 
obtained from the salesperson who is quoting from the media literature (which is not 


correct).’ No confirmation of PacBell’s ISDN equipment and specifications is performed. 


‘We called PacBell and talked to a sales representative who said that their ISDN 
was 2B+D and that the B channels were capable of speeds up to 64 Kbps. When asked 
about the switch software, she didn’t know what we were talking about. She put us on 
hold for five minutes and came back and said the software was National ISDN and not 
Custom. NPS Base Communications spoke with their PacBell technical representative 
who said that all their switches in Monterey were Custom. 
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Another organizational boundary is the vendor of the NT1. This technician needs 
to know how the NT1 works with the TE] or TE2 (which might be yet another vendor). 
The technician also needs to know how the NT1 works with the ISDN line (U interface). 

The next organizational boundary 1s the vendor of the TE1. This is not necessarily 
the same vendor as the NT1. The technician’s responsibility is to know how the software 
configuration works with the CO switch and the interaction with the NT 1. 

Given the many problems reported in the Experimental Results chapter, each 
organizational entity was quick to point fingers at the other. Both PacBell and NPS Base 
Communications questioned whether the ppp software was configured properly. 
Hardware vendors of the equipment blamed problems on the switch software. The end 
result is that the user does not receive timely technical help which exacerbates the 
problem. We expect that most sites would have cancelled the entire connection. We are 
persevering to continue testing this technology despite the fact that many problems 
(including line reliability) are unresolved. 

Another issue which created a problem in this case study 1s the organizational 
structure of NPS and interaction between the individual departments of the organization. 
NPS Base Communication is a tenant command. They are responsible for all 
communications within the NPS campus. When a user puts in a work request to Base 
Communications, it is prioritized based on work for other users within this organization. 
The job request is considered closed once the work is performed and the line is installed. 


If the user is having problems getting that line to work, another work request is generated 
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to have the line tested. Again, this new work request is prioritized based on other work of 
other users. Satisfactory testing must be a condition for completion of work. 

Suprisingly, the user who 1s using the technology is not considered the customer of 
the service provider. NPS Base Communications is the official customer. Therefore, the 
user cannot acquire technical help directly from PacBell. The request for technical help 
has to be initiated through NPS Base Communications.” This situation is unsatisfactory. 

Getting technical help from vendors about ISDN equipment is also a complex 
issue. The maintenance agreement for SGI equipment has one point of contact for the 
entire school. This individual is outside the department requesting the technical help. This 
causes a problem because a second party gets involved who relays the information to the 
vendor. Sometimes the detailed complexity of the issue gets lost in the translation. This 
causes additional problems and compounds the difficulties experienced. 

This experiment attempted to connect a workstation within Root Hall to another 
workstation outside of the boundaries of Root Hall. This was the simplest possible 
realistic test we could devise. However this meant getting another system administrator 
involved. This can cause a problem because an agreement has to made prior to the 
experiment to make the project a responsibility for both system administrators. Often 
projects that are not the responsibility of both departments, get pushed to the end of the 
job priority list. 

*Base Communications at the time of this writing did not have a technician 


experienced with ISDN. ISDN training is planned for one technician. Additional training 
for a second individual is recommended. 
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When doing a technical thesis, the student has to rely on the system administrator 
of that department for assistance. The system administrator is the superuser for the 
network and is the only one who can make changes to the network. This was an issue in 
this case study because there were many students who needed administrator assistance. 
The administrator has other duties and responsibilities and it becomes very difficult to 
schedule priorities. The problem is compounded when crossing organizational boundaries 
because now the student is dependant on two system administrators and not one. 
Frequent coordination and patience are essential. 

CG; EXPERIMENTAL RESULTS 

It was experimentally verified that ISDN provides a bandwidth up to 112 Kbps. 
However it was not experimentally confirmed whether the switch supports a full 128 Kbps 
(2 B channels at 64 Kbps each). It appears that our link supports 112 Kbps (2 B channels 
at 56 Kbps each). Additionally it was determined that ISDN is not a completely reliable 
technology because the line continues to fail and diagnostic efforts have been inconclusive. 

All tests to determine whether ISDN supports native IP multicasting were 
negative. An SGI technical representative said that there is a bug in the ppp software 
which causes their ISDN solution to not support multicasting. However an individual 
from the MBone Users Group stated that he uses SGIs with Ascend products and it 
supports multicasting. His solution and others are attached as Appendix E. Their results 
each use unicast tunnels over ISDN to provide multicast at each end. This is consistent 


with the results found in this thesis. 
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D. RECOMMENDATIONS FOR IMMEDIATE ACTION 

When dealing with a new technology, one person should be in charge of the whole 
process. The individual should be responsible for buying the phone lines, buying the ISDN 
equipment and having superuser privileges on both ends of the link. Crossing 
organizational boundaries only creates problems. If NPS Base Communications is 
responsible for all communication technology, then their technicians need to be properly 
trained and capable of answering user’s questions. NPS Base Communications needs to 
obtain documentation from the ISDN service provider pertaining to the information 
necessary to make the ISDN equipment compatible with the service provider’s equipment. 
All installations (regardless of technology) should be coordinated prior to the setup date in 
order to have all responsible individuals present so that questions can be answered. NPS 
Base Communications must not consider a work request closed unless the technology is 
working properly. We recommend that NPS Base Communications correct these 
problems. 

To achieve success using ISDN, the responsible individual should choose an ISDN 
solution with the largest market share, or contract a consultant to buy an interoperable 
package. This consultant is a liaison between the ISDN service provider, hardware and 
software providers. The consultant is responsible for maintenance and training support as 
well as a working product. We recommend training two NPS technical staff members to 


become as proficient as an ISDN consultant in these areas. 
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More system administrators need to be employed if assisting students with thesis 
work is a priority. There are too many students with technical theses and too many other 
user requirements that need the support of three STL system administrators in Root Hall. 
More administrators are needed.” 

A visit to the local PacBell office, visual inspection of the ISDN switching 
equipment and dialog with the cognizant technical expert will likely resolve many of these 
open issues. Of particular interest is the means by which PacBell diagnoses line problems. 
E. RECOMMENDATIONS FOR FUTURE WORK 

When the issues of reliability, capacity and multicast compatibility are resolved, 
ISDN needs to be evaluated again to determine if it is a viable solution to extending LAN 
connectivity. Specifically, ISDN needs to be tested across different operating system 
platforms to determine interoperability especially when dealing with MP. National and 
global ISDN standards still need to be tested to also determine interoperability issues. 
ISDN needs to be tested for long distance and international telecommuting. The final 
issue is multicasting. Although this thesis successfully demonstrated IP over ISDN, 
multicast usability needs to be verified. This includes remote LAN monitoring from home 
to include network monitoring pages (Edwards, 96) (Erdogan, 96). Once this is 
successfully accomplished, it is recommended that STL purchase the ISDN technology 
and ISDN equipment for system administrative security reasons as well as to test 


telecommuting effectiveness. 


Further hiring actions are in progress to correct this situation. 
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New technologies, need to be evaluated after they enter the marketplace to venfy 
that the technology does everything that the specifications say it does. Information 
Technology managers need to carefully test products and analyze them thoroughly before 
making a decision to use it. Buying into media hype and marketing promises will often 
pull the manager in the wrong direction and possibly cost more money. It is the 
responsibility of the Information Technology manager to examine new technologies and 
find the one that best suits the organizations needs, infrastructure and future plans. 

F. CONCLUSION 

Although this experiment to test ISDN was only partially successful, there were 
many technical and managerial lessons learned which can be taken away from this case 
study. DoD must make a concerted effort to evaluate both ongoing and future programs 
which will implement new technology in order to ensure that the technology increases 
mission capability in the most beneficial and cost effective manner. Information 
Technology managers have a responsibility to make intelligent recommendations based on 
fact and not media hype. Finally, ISDN capabilities have progressed since the three fatal 
showstoppers identified in (Bigelow, 96). The corrections are not yet complete however. 
We remain optimistic that ISDN will mature into a data link technology capable of 


effectively extending Internet-compatable LAN connectivity. 
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APPENDIX A 


INTENATIONAL DATA CORPORATION’S 1995 TELECOM MANAGERS 
SURVEY 


Respondents’ Use of Subscription Telecom Services 
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APPENDIX B 


ISDN BASIC RATES IN THE UNITED STATES 


Ameritech 


Service Monthly Installation Minutes Per Add’l 
Included Minute 
lilinois 28.19 135.00 local rates 
Residential 
Michigan B35) 122.00 local rates 
Residential 
Ohio 32.20 116.50 
Residential 
Wisconsin 30.90 113.05 
Residential 
Illinois 33.60 132.35 
Business 
Michigan 37.46 147.00 local rates 
Business 












local rates 









local rates 


local rates 


local rates 


Ohio Business’ | 40.60 129.35 


37.00 100.65 
Bell Atlantic 


Business ISDN | 41.88 25100 | 


Available at hitp://www.xmission.com/isdncomp.html 


Wisconsin local rates 


Business 







Residential 
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NYNEX 


Service Monthly Installation Minutes Per Add’l 
_— a 


Residential —_| 28.35 S257 | toca rate rate 


Pacific Bell 









Southwestern Bell 


45.50 sass | ooo |e 





US West 


[condo foo [ero | aint! 
waninson [soo [sso ‘| —o | owns 
Twasinson [soo [500 | annie | 


Utah (proposed) 


39.00 nooo | 
200 Hour 68.00 110.00 12000 
184.00 110.00 |—unlimited | 


*larger installation fee waived with minimum service 
+day/night 
++first minute/additional minutes 




















Available at hitp://www.xmission.com/isdncomp.html 
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APPENDIX C 


DEBUGGING SCRIPT FOR ISDN PPP SOFTWARE OUTPUT 


ppp[1666): rambo IPCP2: Req-Sent (6) ->Starting (1) 


ppp [1666] : 
ppp [1666]: 
ppp [1666]: 


ppp [1666] : 


ppp [1666] : 


ppp [1666] : 


ppp [1666]: 


ppp [1666] : 


ppp [1666]: 
ppp [1666]: 
ppp [1666]: 
pee li66e] : 


ppp [1666] : 


ppp [1666]: 


ppp [1666]: 


rambo 
rambo 
rambo 
rambo 
fl 00 
rambo 
rambo 
O02 Ja 
rambo 
rambo 
05 06 
rambo 
rambo 
rambo 
rambo 
rambo 
sync 

rambo 


rambo 


LCP2: send Configure-Request ID=Oxfl 
LCP2: magic=Ox6907c18E£ 

LCP2: receive compressed protocol field 
2: send Oxc bytes: index=1ll proto=Oxc0O21 01 
Cle MOSM OS MS MS. 

LCP2: send Configure-ACK ID=0x7a 
2; send Oxic bytes: index=11 proeo-Oxcozm 
00 16 O1 04 QO5 

LCP2: Opened (9) ->Ack-Sent (8) 

2: read Oxc bytes: proto=OxcO21 02 fi 00 Oc 


Cio Opec oa 


LCP2: receive Configure-ACK ID=Oxf1l 
LCP2: event RCA 

LCP2: action TLU 

LCP2: MTU=1500 MRU=1500 TOS 

LCP2: my magic—Ox6é907cl18f£,his-Ox6907991£ 


2: entering Authenticate Phase 


AUTH2: will send PAP requests but receive 


no authentication 


103 


ppp[1666]: rambo AUTH2: send PAP request ID=0x89 

ppp[1666]: rambo 2: send Oxll bytes: index=1l proto=0xc023 
01 89 00 11 04 "baby’ ) 

ppp[l16é66]: rambo LCP2: Ack-Sent (8) ->Opened (9) 

ppp [1666]: rambo 2: read OxlO bytes: proto=0x8021 01 05 00 
ORC Z 0G UO + Za Ome) 

ppp[1666]: rambo IPCP2: discard Configure-Request because in 
Authenticate, not 

ppp[1666]: rambo 2: read Oxll bytes: proto=O0xc0O23 02 89 00 
11 O¢ “why is thisi# 

ppp[1666]: rambo AUTH2: receive PAP Ack ID=Ox89 containing 
WWiny IS sthas 2! 

ppp[1666]: rambo 2: entering Network Phase 

ppp[1666]: rambo LCP2: set sync, acomp=0, pcomp=0, 
rx_ACCM=0, tx=0,pad=0 

ppp[1666]: rambo IPCP2: event Up 

ppp [1666]: rambo IPCP2: send Configure-Request ID=Oxda 

ppp [1666]: rambo IPCP2: 16 slot VJ compression without 
compressed slot IDs 

ppp [1666]: rambo IPCP2: ADDR our address 131.120.7.116 

ppp [1666]: rambo 2: send OxlO bytes: index=11l proto=0x8021 
Ci=das00 10 [0Zeigen00 

ppp[1666]: rambo IPCP2: Starting(1) ->Req-Sent (6) 

ppp[1666]: rambo 2: read OxlO bytes: proto=0x8021 02 da 00 


nO O2 "Hoe a0T2d Of 00 
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ppp] Gas | - 
pep [L666 )— 
ppp [1666]: 
ppp [1666] : 
ppp [1666] : 


ppp [1666]: 


ppp [1666]: 


pep h66o] : 


ppp [1666]: 


ppp [1666] : 


ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 


pep (1666) : 


ppp [1666] : 


ppp [1666] : 


ppp [1666] : 


ppp [1666] : 


rambo 


rambo 


rambo 


rambo 


rambo 


rambo 


IPCP2: 


IPCP2: 


LPCEZ: 


IPCP2: 


rPCP2% 


IPCP2: 


receive Configure-Ack ID=Oxda 
event RCA 
Req-Sent (6) - >Ack-Rcvd (7) 

event TO+ #0 

send Configure-Request ID=Oxdb 


16 slot VJ compression without 


compressed slot IDs 


rambo 


rambo 


Olds 


rambo 


rambo 


OmOz 


rambo 


rambo 


rambo 


rambo 


rambo 


rambo 


IPCP2: ADDR our address 131.120.7.116 


2: send OxlO bytes: 


in@dex=liioroto=—0Ox3d021 


00 LTO 02 G6 00 


IPCP2: Ack-Rcvd(7) ->Req-Sent (6) 


2: read OxlO bytes: proto=0x8021 02 db 00 


06 OO 


IT PCP2: 


IPCP2: 


IPCP2: 


I PGP26 


IPCP2: 


IPCP2: 


DAMVOL OO 
receive Configure-Ack ID=Oxdb 
event @REA 
Req-Sent (6) ->Ack-Rcvd (7) 
event TO+ #0 
send Configure-Request ID=Oxdc 
16 slot VJ compression without 


compressed slot Ids 


rambo IPCP2: ADDR our address 131.120.7.116 


rambo 


Oiale 


rambo 


rambo 


2: send OxlO bytes: 


index=11l proto=0x8021 


OOO" 02 FOGROO 


IPCP2: 


Ack-Rcevd (7) ->Req-Sent (6) 


2: read OxlO bytes: proto=0x8021 02 dec 00 
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ppp [1666]: 
ppp [1666] : 
ppp [1666] : 


ppp [1666]: 


ppp [1666] : 


ppp [1666]: 


ppp [1666]: 


ppp [1666] : 
ppp [1666]: 


ppp [1666] : 


ppp [1666]: 
Beriblese)! : 


ppp [1666] : 


ppp [1666] : 


ppp [1666]: 
peel l6e6) = 
ppp [1666]: 


ppp [1666] : 


we O02 
rambo 
rambo 
rambo 
rambo 
noe O02 
rambo 


rambo 


(but use 16) 


rambo 


O60. 2de0Ff..00 

IPCP2: receive Configure-Ack ID=Oxdc 
IPCP2: event RCA 

IPCP2: Req-Sent (6) ->Ack-Rcvd (7) 

a: meadmO@sclO wayt es: -pReto=—OxS02d— 01 06) 00 
06 00a2a 10700 

IPCP2: receive Configure-Request ID=0x6 
IPCP2: accept 17 slot VJ header compression 
wit 


IPCP2: accept its address 131.120.7.49 from 


ADDR Request 


rambo 
rambo 
rambo 
OZe065 
rambo 
rambo 


rambo 


Tae 


rambo 


rx ACCM=0, 


rambo 


rambo 


rambo 


rambo 


IPCP2: event RCR+t 


IPCP2: send Configure-ACK ID=O0x6 
2: send OxlO bytes: index=11 proto=0x8021 
O00 10°02 06.00 

IPCP2: action TLU 

IPCP2: Ack-Rcvd(7) ->Opened (9) 
EPCP2: ready 1319120777116" to 131.120.7 sage 
COMpSyrex=-yer 

LCP2: set sync, acomp=0, pcomp=0O, 
tx=0,pad=0 

CCP2: event Open 
CCP2: ace1Gn@ EES 
C@P2) Ima Cialm®) - >Starting (19 


CGP2Z sey cnesUp 
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ppp [1666]: 


ppp (1666): 


ppp [1666] 


ppp [1666]: 


ppp [1666]: 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
Ppp |1666] : 


ppp [1666] : 


ppp[1666]: 
ppp [1666]: 


ppp [1666] : 


ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp[1666] : 


rambo CCP2: 


send Configure-Request ID=Oxe3 for 12 


bit BSD Compress a 


rambo 2: send Ox9 bytes: index=11 proto=Ox80fd 01 
es 00 0S” 15m02 2ce20 

:rambo CCP2: Starting(1) ->Req-Sent (6) 
rambo 2: read Ox7 bytes: proto=Ox80fd 01 46 00 O7 
1S03. 2C 
rambo CCP2: receive Configure-Request ID=0 ~46 
rambo CCP2: turn off TX compression 
rambo CCP2: accept 12 bit BSD compression 
rambo CCP2: event RCR+ 
rambo CCP2: send Configure-ACK ID=0x46 
rambo 2: send Ox7 bytes: index=11 proto=Ox80fd 02 
46°00" 07 Siamese 
rambo CCP2: turn on/reset TX 12 bit BSD Compress 
rambo CCP2: Req-Sent (6) ->Ack-Sent (8) 
rambo 2imecad OM7 bytes: proco=-Oxs0kd 02 e353 00707 
LEMOS eZe 
rambo CCP2: receive Configure-ACK ID=Oxe3 
rambo CCP2: turn on/reset RX 12 bit BSD Compress 
rambo CCP2: event RCA 
rambo CCP2: action TLU 
rambo CCP2: Ack-Sent (8) ->Opened (9) 
rambo: TCP/IP activity: busy 
rambo: TCP/IP activity: busy 
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Beep lisse |= 
ppp [1666]: 
ppp [1666]: 
ppp [1666]: 
ppp [1666]: 
Per Eso: 
ppp [1666]: 
Denes 6G |x: 
ppp [1666]: 
Pp | 1666 ii: 
Doel 1666 lr 
ppp [1666]: 
ppp [1666]: 
ppp [1666] : 
ppp [1666]: 
jaj@ | LS Slee 
ppp [1666] : 
ppp [1666]: 
ppp [1666] : 


pep ec] : 


ppp [1666] : 
ppp [1666] : 
ppp [1666]: 


ppp [1666] : 


rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
Gamo: 
rambo: 
rambo: 


rambo: 


rambo 


rambo 


rambo 


rambo 


477 QO 


rambo 


rambo 


rambo 


rambo 


REP/ IP sacbivity:ebusy 
TCP/IP activity: busy 
TOP/IP activity sebusy 
TCP/IP activity: busy 
TCP/IP activity: busy 
TEP/IP.achinvalty busy 
TED/ TP Pactivity-. busy. 
TCP/IP activity: busy 
TCP/IP activity: busy 
TCP/IP activity: busy 
TCP/IP activity: busy 
TGP/ Tl Peactiviley: Susy 
TCP/IP activity: moderate 
TCP/IP activity: busy 
TCP/IP activity: busy 
TCP/IP activity: moderate 
2: read Ox4 bytes: proto=Ox80fd Oe 47 00 04 


CCP2: receive Reset-Request ID=0x47 
CCP2: send Reset-Ack ID=0x47 
2: send Ox4 bytes: index=11 proto=Ox8s0fd Of 
04 
CCP2: turn on/reset TX 12 bit B5D Compress 
2: read Ox4 bytes: proto=Ox80fd Oe 48 00 04 
CCP2: receive Reset-Request ID=0x48 


CCP2: send Reset-Ack ID=0x48 
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ppp [1666]: 


ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666]: 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666]: 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666]: 


ppp [1666] : 


ppp [1666]: 


ppp [1666] : 
ppp [1666] : 
ppp [1666]: 


ppp [1666] : 


rambo 2: 


48 00 04 


send Ox4 bytes: 


imdadex=11 proteo-—Ox80%d0 OF 


rambo CCP2: turn on/reset TX 12 bit BSD Compress 


rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 
rambo: 


rambo: 


TCGRALPeaclivityesilow 
TCP/IP activity: low 
TCP/IP activity: moderate 
TCP/IP activity: busy 
TCGRyalbe activ say : ebusy 
TCP/GP activityem@biscy 
TCP/IP activity: busy 
TCP/IP activity: busy 
TCP/IP activity: busy 
TGP/IP.aetivity™ busy 
TCP/IP activity: busy 
TCP/IP activity: moderate 


rambo 2: inactivity timeout; /dev/isdn/modem_b2 


rambo LCP2: 


event Close 


rambo LCP2: send Terminate-Request ID=Oxf2 


"Inactivity timeout" 


rambo 
OS tei 
rambo 
rambo 
rambo 


rambo 


2: send Ox1l6 bytes: index=11 proto=Oxc0O21 


00 16 "inactivi 
LCP2Z: action TLD 
IPCP2: event Down 
LTPCE2wach1one. LhD 


IPCP2: Opened (9) ->Starting (1) 
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ppp [1666]: 
ppp [1666]: 
PPPS) : 
ppp [1666]: 
ppp [1666]: 


ppp [1666]: 


ppp [1666] : 


Dee Voce! : 
ppp [1666]: 
ppp [1666] : 
ppp [1666]: 
pep (heee] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 
ppp [1666] : 


ppp [1666]: 


rambo CCP2: event Down 

rambo CCP2: action TLD 

rambo CCP2: Opened (9) ->Starting (1) 
rambo LCP2: Opened (9) ->Closing (4) 

rambo 2: entering Terminate Phase 


rambo 2: read Ox16 bytes: proto=Oxc0O21 06 £2 00 
16 "inactivity timeo~ 
O6nf2 OGRE 


rambo LCP2: receive Terminate-Ack: 


"Inactivity timeout" 


rambo LCP2: event RTA 

rambo LCP2: action TLF 

rambo 2: entering Dead Phase 
rambo: Closing (4)->Initial (0) 
rambo: TCP/IP activity: low 
rambo: TCP/IP activity: low 
ramoe) >> Line “ort: 


rambo 1: /dev/isdn/modem bl off 
+ route delete default 131.120.7.49 
delete net default: gateway 131.120.7.49 


rambo: exiting with O 


110 


APPENDIX D 


DEBUGGING SCRIPT FOR PRE-TUNNEL ERROR MESSAGE 


rambo 


debug 


leeZ2i6e 


Lis26. 


didis 26a: 


i= 6 


Ane 6: 


1# /uer/etc/mrouted -d 
level 2 
01.511 mrouted version 3.8 


01.633 Getting vifs from kernel interfaces 
01.634 installing ecO (131.120.7.49 on subnet 


ede. 1 20.27/24) “asvvit- #0 — ra 


701.635 Getting vifs from /etc/mrouted.conf 


01.677 can’t forward: only one enabled vif 


AAAAAAAAAAAAAAAAAAAA 


Lee 








APPENDIX E 


E-MAIL FROM MBONE USERS 


Date: Thu, 31 Aug 1995 09:44:11 PDT 
From: Bill Fenner <fenner@parc.xerx.com> 
To: Davidwfox@eworld.com 

CC: rem-conf@es.net 


Subject: Re: ISDN & M-Bone 


In message <950830154851_ 14164706@eWorld.com> you wntte: 
>Just about to install 128k ISDN connected to Mac server network in our home. Will we 


be able to connect to the M-Bone and if so, what special equipment do we need?< 


I occasionally run a tunnel over my ISDN link, it works very well for audio and if you do 
priority dropping you can get some vague idea of what the video is supposed to look like. 
You need a multicast capable router at your home. I’m pretty sure that MacTCP doesn’t 
do multicast forwarding; I don’t know if MachTen does or not. You might need to find a 
UNIX box (e.g. a cheap PC running FreeBSD) to put at your end. Or, if the ends of the 
ISDN line are real routers, (as opposed to a bridge), you might be able to turn on 


multicast forwarding on them. Bill 


IS 


Date: Sun, 28 Aug 1994 20:20:49 +0900 
From: Hitoaki Sakamoto <hitoaki@sphere.csl.ntt.jp> 
To: rem-conf@es.net, MBONE@isi.edu 


Subject: Re: ISDN, PPP, and MBONE 


<Does anyone know of someone using ISDN to support an MBONE connection? I 
would be particularly interested to know if anyone is using an SGI Indy or Sun ( which 
have a ISDN port) with ISDN for MBONE use.> 

I am using the MBONE with ISDN at home. I have a Sun IPX with ISDN S-bus 
board (from CSR, not SUN original). This board is very useful, because it can use 2 B 


ch (128 Kbps). 


Date: Sat, 27 Aug 1994 22:22:31 -0700 

From: Paul Traina <pst@cisco.com> 

To: Michael Macedonia<macedoni@fravyl.cs.nps.navy.mil> 
Cc: MBONEQ@ISLEDU 

Subject: Re: ISDN, PPP, and MBONE 


<Does anyone know of someone using ISDN to support an MBONE connection?> 


Yes, I am using PPP over ISDN, however I’m using PIM/sparse as opposed to DVMRP 
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to carry my routing information. DVMRP (and PIM/dense) is not well suited to using a 
low bandwidth link with a low threshold limit (as an example, a link between work and a 
telecomuter at home who want’s to receive local work multicast transmissions) because 
you get periodic blasts of multicast traffic until your prune messages get back (assuming 
you have a mrouted that listens to prunes at all). Before I switched to using PIM in 
sparse mode, every time a prune message would expire, I’d get a blast of packets down 
my link until the packets were processed and a prune message was sent back. Now you’d 
tend to think that this should happen really fast, and it does, but it’s really annoying to 


see that 1 second freeze every n seconds. 


Return-Path: <e93_mda@it.kth.se> 

To: Irmihlon@nps.navy.mil (Lauren R Mihlon) 

CC: magda@it.kth.se, e93_ mda@it.kth.se 

Subject: Re: ISDN and MBONE 

Date: Tue, 09 Jul 1996 22:57:36 +0200 

From: Magnus Danielson<e93_mda@it.kth.se> 

Hi! I think that the tech support was wrong or at least slightly wrong. Now, this is how I 
be.. bring MBONE to my home Indy over ISDN: 

1) run Inx 5.3 

2) I have patched it with the multicast routing patch that is freely available from SGI. 


The kernel patch is for mrouted 3.5 and above and you also get an mrouted 3.8 along 
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with it. 

3) I have patched the OS with the ISDN patch. 

4) I have configured it to do 2 X 64 Kbps which is supported. 

5) In the other end I have an Ascend primary-rate box. 

6) I have a mrouted multicast router in the other end. 

7) I configure a multicast tunnel between my box and the multicast router. 
5.5) My Indy has its own IP number space!!! 

8) The address space is split so that a 4 address range ( this is called /30 for the netmask... 
I will use that term from this point) is dedicated to the ISDN line. The Ascend has the 
lower address and the Indy has the higher ( or the other way around.. doesn’t really 
matter) like this: 

x.x.x.112 lower broadcast 

x.x.X.113 Indy ISDN port 

x.x.x.114 Ascend ISDN port 

x.x.x.115 upper broadcast 

These numbers shows the real layout of my box and the base 

x.x.x.112 may be changed to whatever you like. 

Now, the Indy ethernet port MUST be on another subnet than the ISDN port in order to 
allow mrouted to route traffic. This network might be as small as a /30 or bigger... so 
you can let the Indy route traffic to other machines. 


9) I use both sd, vic and vat with success. Wb also runs great once you have learned to 
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avoid the x server postscript bug. Last time I tried to use sd I did have trouble.but on the 
other hand was the MBONE pretty upset that day so I went for a point-to-point thing 
instead. 

I do recommend you to run the SNMP mrouted in both ends and learn to use the tools. 
my home Indy was the Indy I did my half of the SNMP mrouted port on. 


Good luck Magnus 


le? 





nn am a ae re 
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